How a supplier's bill gets entered, checked against the order and the delivery, signed by the right people, and finally marked as settled somewhere else.
What the queue is for
A supplier invoice says what you owe. The order says what you agreed to buy, and the goods receipt says what actually came off the lorry. The invoice queue puts the three side by side, and the match between them decides whether Finance can sign the bill, whether somebody has to justify a difference first, or whether the document can't be approved at all until something underneath it is fixed.
One thing to be clear about from the start: approving an invoice here means "this bill is correct". It moves no money. Settlement happens in your own finance system, through TendePay or the bank, and Bohari only records that it happened.
The screen needs view_procurement or manage_supplier_invoice. An Auditor can read every invoice and see no buttons at all, and that's deliberate. If you're pinned to an outlet you see that outlet's invoices only, since an invoice belongs to the branch whose order it bills.
The piles
Everything is fetched once and sorted into tabs, with a count on each:
| Tab | What lands here |
|---|---|
| Needs decision | Matched and Flagged invoices, oldest first. This is the work. |
| Blocked | Blocked invoices, plus any whose match never ran. Nothing here can be decided until a document underneath is fixed. |
| To settle | Approved, waiting for a settlement record. |
| Closed | Settled, rejected or cancelled. |
| All | Everything. |
Filters along the top are Search (invoice number or supplier), Supplier, From and To. They narrow the set before the tabs are counted, so a tab's number always describes what you'll see when you press it, and they live in the URL, so "the blocked pile for Kenya Breweries" is a link you can send someone. Export downloads the tab in front of you, with the expected figure beside the stated one.
Each row shows the stated subtotal ex VAT and a Difference column: stated minus expected. Positive is against you, negative is in your favour, and a dash means the match couldn't compute an expected figure at all, which is not the same as zero.
Entering an invoice
Enter invoice (needs manage_supplier_invoice) opens a form that records what the paper says and nothing else. Pick the supplier, then one of their orders. Only approved, part-received or received orders are offered, because the server refuses anything else: "Cannot invoice against a draft purchase order". Type the invoice number exactly as printed. It's half of the duplicate check, and the same number from the same supplier is refused with "Invoice INV-2231 has already been entered for this supplier."
The order's lines appear with the item, SKU and VAT rate filled in, and the quantity, price and pack size left blank. That's on purpose. If the form showed you the ordered price you'd anchor to it, every invoice would agree, and the check would be dead while looking alive. Key what the supplier billed, in their purchase units, ex VAT. Remove any line the invoice doesn't carry. If they billed something nobody ordered, use Add a line that is not on the order; it will block the invoice as "not ordered", which is the point, because it records the claim so someone can ask for a credit note.
The totals at the bottom are typed separately from the foot of the page, never summed from the lines. The server checks the two transcriptions agree and refuses a mismatch: "The lines entered total KES 48200 but the invoice states KES 42800. Check the entry before continuing." Better to catch your own typo now than to flag the supplier for it later.
Enter and match saves the invoice and runs the match straight away.
What the match checks
Everything is compared in stock units and ex VAT, so a supplier who ships cases of 24 where your item default says 12 is not out by 100% on every line. The comparison runs per order line, grouping any invoice lines for the same item together, so billing the same ten crates twice on one invoice is caught rather than passing twice. A second invoice quoting a delivery an earlier invoice already billed is caught the same way.
Each line gets one finding:
- OK: price and quantity both within tolerance.
- Price, Quantity or Price & quantity: a difference worth a look. The invoice is flagged and can still be approved.
- No delivery: nothing confirms these goods arrived. The invoice is blocked. Receive the delivery, then Re-run match.
- Not ordered: no order line to check against. Blocked; needs a credit note or a corrected invoice.
- Over-invoiced: billed for more than was accepted at the bay. Blocked, always. There's no version of this a senior signature should push through.
The tolerances live on the Procurement settings screen and belong to a Tenant Admin. Out of the box, a price may drift 2% of the agreed line value, never less than KES 100 and never more than KES 2,000. Counted items (bottles, crates) get 0% quantity tolerance; weighed or poured items get 1%, because a 20 kg bag that weighs 19.9 kg is the scale, not a dispute. A separate check on the whole document catches ten lines each 1.9% over: the total may drift 1% of the expected subtotal, with a floor of KES 1,000. A pack size that differs from the order is noted but never flagged on its own, since six cases of 24 and twelve of 12 are the same 144 bottles.
A block is not a severe flag. It's a different kind of answer, and the banner at the top of the invoice names the thing that clears it.
Approving, and who may
The ladder is worked out from the invoice's stated subtotal ex VAT and the current thresholds, every time the page opens. At or below KES 50,000 one Finance approver signs (approve_supplier_invoice). Above it, Finance signs first and a Tenant Admin second (approve_supplier_invoice_admin). One person can't take both rungs: "You have already approved this document; a second approver is required." The Approval card on the right shows the ladder, who has signed, and any reason they gave.
A flag doesn't lengthen the ladder. What it changes is whether you must write a reason. If any difference costs the business money (over-priced, or the total drifts against you), approving demands one: "This document has an unresolved variance; approving it requires a reason." Being under-charged for sukuma wiki flags the line and asks nothing of you. Rejecting always needs a reason. Write it for the negotiation: one accepted variance is noise, forty against the same supplier is a conversation.
Two more rules the server enforces about the person rather than the role:
- Before the first signature the match re-runs against today's deliveries. If a receipt was reversed since entry and the invoice now blocks, approval is refused with the fresh finding.
- Where your thresholds let a single approver sign above the distinct-approver threshold (KES 250,000 by default), whoever approved the purchase order is refused as that sole approver: "You approved the purchase order behind this invoice, and you would be its only approver."
On the Needs decision tab, anyone holding approve_supplier_invoice also gets a checkbox on every clean match (Matched, with a difference of exactly zero) and an Approve N clean matches button. Flagged and blocked rows never get one; those are the invoices the queue exists to make somebody read.
Reject, cancel, and re-run
Reject says the bill is wrong. Cancel invoice says it shouldn't be in the queue at all: the supplier withdrew it, it was keyed twice, or the delivery behind it is being unwound. Both need a reason, and they're kept apart in the audit trail. Cancelling is also the only way out of an approved invoice, and the only thing that frees a goods receipt to be reversed once its invoice has been signed. A settled invoice can't be cancelled; the money moved.
Re-run match is offered until somebody signs. After that it's refused: "This invoice already carries an approval; re-matching it would change the findings underneath a signature. Reject it and enter a corrected invoice."
Settlement and what's outstanding
Once an invoice is approved, anyone with record_settlement sees Record settlement on it. The reference from TendePay or the bank is required, because a record nobody can look up is no better than no record. Part settlements are fine; the balance stays outstanding until the inclusive total is covered, at which point the status flips to Settled. Over-recording is refused: "Only KES 12400 is outstanding on this invoice; cannot record 15000."
The person who approved the invoice can't record its settlement: "You approved this invoice; settlement must be recorded by somebody else." A wrong record isn't edited. Correct this record supersedes it with a new one and a required reason, and the old row stays in the history, struck through.
Outstanding by supplier groups every approved-but-unsettled invoice under its supplier with a subtotal and a plain day count. There's no grand total, no ageing buckets and no due dates, because those belong to the finance system. This page answers one question: should we raise another order with this supplier right now?
FAQ
Why can't the storekeeper approve the invoice for what they received?
Because the person who says the goods arrived must not also be the person who says the bill is right. The Storekeeper role holds receive_goods and deliberately not approve_supplier_invoice; Finance holds the approval and deliberately not receive_goods. Give one person both and a delivery that never happened can be invoiced and approved by the same hands. See Roles & Permissions.
The invoice is blocked with "No delivery" but the crates are in the cold room. Then the delivery was never booked in against that order. Check the order's deliveries list; if the receipt is missing, record it (on the phone at the bay, or from the order's Receive delivery), then come back and Re-run match. If the stock was booked in some other way, Stock on Hand will show you how.
We were under-charged. Why is the invoice flagged at all? So you can see it. Under-billing costs nothing today, so no reason is demanded and the line reads "in our favour", but it usually means the price list is stale or the supplier's packaging changed. Approve it and fix the price list.
Why does the invoice I approved this morning still sit in To settle?
Because nothing has been recorded against it. Approval is "the bill is correct"; settlement is a separate note that money left, with a reference. Until someone with record_settlement writes that down, the invoice is outstanding.
Can I photograph the invoice instead of typing it? Not yet. There's no reading engine configured, so entry is by hand, and receiving never waits on one.