Supplier Bills, Returns & Payment Runs

A supplier bill is the supplier’s invoice captured once in AWRA, so that what you owe them is a record rather than a folder of paper. You open it from Procurement → Purchase Orders, in the row of links for purchasing and payables, and the bills list shows three figures across the top: what is owed to suppliers, what is overdue, and what is waiting for review. There are two kinds of bill and the difference matters for the books. A bill against a purchase order is for goods that came through receiving: the payable was already booked when the check-in was approved, so approving the bill posts nothing for the goods themselves — it is the document you pay and the third leg of the three-way match. If that bill carries VAT, approval books the VAT part to input tax against accounts payable.

A bill without an order is for rent, electricity, a consultant or a courier — anything that never went into stock. Here the bill is where the cost first reaches the books, so each line can carry its own expense account; a line without one falls back to the bill’s expense account, and then to operating expenses. Expense bills can also be tagged with a department, branch and project so the income statement can be read by those dimensions. When you capture a bill against an order, Prefill from the order brings in each line with the quantity actually received — what the supplier should be charging for — and the order price. With no due date entered, a bill falls due 30 days after its bill date.

In practice: a Nairobi hardware distributor receives 400 bags of cement against a purchase order at KES 780 a bag. The check-in is approved, which books KES 312,000 to inventory and accounts payable. The supplier’s invoice arrives for KES 361,920 including 16% VAT. The clerk captures it against the order, presses Prefill, enters the supplier’s invoice number and attaches the PDF. On approval the goods post nothing new; only the KES 49,920 of VAT is booked to input tax. The same week, the office rent invoice of KES 85,000 is captured as a bill with no order, its line set to the rent expense account and tagged to the Westlands branch — and that bill does post the expense on approval.

Most of what goes wrong in payables is paying something twice or paying more than was agreed, so the bill carries several refusals that run on the server rather than relying on someone noticing. A supplier’s invoice number can be captured once per supplier: keying it again is refused, and the message names the bill it was already captured as. Approved bills against one purchase order may not add up to more than the order total, plus any price tolerance set for your workspace — zero unless support has set one — and a bill that would push past it is refused at approval. A purchase order from a different supplier, or a line that is not on the chosen order, is refused. And a bill against an order can only be paid if the order passes the same payment match check every supplier payment screen uses.

Once approved, a bill is fixed: only a draft, submitted or rejected bill can be edited, so changing an approved one means cancelling it and capturing it again. Cancelling works only while nothing has been paid or credited against it, and cancelling an approved expense bill reverses its journal line for line, tags included. The balance on a bill is never typed: it is recomputed from confirmed payments and applied debit notes, net of any withholding, and the bill moves to Partly paid and then Paid on its own. Suppliers can also submit bills themselves. A supplier signed in to the vendor portal opens one of their purchase orders and uses Submit an invoice, with their invoice number, date, quantity, price and VAT per order line, and a required invoice file. It arrives as Submitted by supplier, everyone who can approve bills is notified, and nothing is payable until someone on your side approves it under the same checks.

In practice: an accounts clerk keys invoice INV-2207 from Mombasa Steel for KES 240,000 on Monday. On Thursday a colleague, working from a forwarded email, tries to key INV-2207 again and is refused with the name of Monday’s bill. Later that month Mombasa Steel submits INV-2241 from the vendor portal against an order worth KES 500,000, of which KES 420,000 is already billed. Their bill is for KES 95,000. The approver opens it, sees the match panel, and presses Approve for payment — and AWRA refuses it, because KES 515,000 would pass the KES 500,000 order total with no tolerance set. The approver rejects it with a reason; the supplier sees that reason on the order page in the portal, corrects the quantity and resubmits, and the corrected bill comes back as submitted for review.

When goods go back to a supplier, two things must happen together: the stock has to leave the warehouse and the supplier has to owe you for it. A supplier return does both. You open Returns & debit notes from the same row of links, press Return goods, and optionally pick the purchase order the goods came on, which fills in the supplier and items and suggests the VAT rate from that order’s bills. You choose the warehouse and location the goods leave from, the date, the VAT rate the supplier charged and the reason, then add the items in whole units — naming the serial numbers for a serial-tracked item. Leaving the unit cost empty uses the order price, or the item’s average cost when there is no order. The return is saved as a draft and approved with Approve — goods have left, which takes the stock out, marks the serials as returned to the supplier, and raises the debit note in the same step.

A return checks what it can. Against an order, every item must be on that order and you can return no more than was received on it and not already returned. Without an order, the item must have been bought from that supplier before. The warehouse and location must hold the quantity at approval. If your team wants preparing and approving to be two different people, an administrator switches on the second-approver setting under Settings → Procurement Defaults; it is off by default for small teams. For credit with no goods moving — a price agreed down after billing, a short-delivery credit or a rebate — Debit note without a return records the amount the supplier owes back including VAT, and the VAT part separately. On approval a return posts Dr accounts payable for the gross value, Cr inventory at what the stock cost and Cr input tax for the VAT, with any gap between the agreed price and the stock cost going to purchase price variance so the inventory account keeps agreeing with the stock valuation.

In practice: a pharmacy chain returns 20 cartons of a short-dated syrup bought at KES 3,000 a carton plus 16% VAT. Approving the return removes the stock and raises a debit note for KES 69,600: Dr accounts payable 69,600, Cr inventory 60,000 (the stock cost matched the order price), Cr input tax 9,600. The supplier has an open bill of KES 150,000. The finance officer opens the debit note, chooses that bill under Set against a bill and applies KES 69,600 — nothing posts, because the payable already fell when the note was raised, and the bill now owes KES 80,400. Had the supplier no open bill and refunded the money instead, Record the supplier’s refund would post Dr bank, Cr accounts payable. If the supplier later refuses the goods, the return is reversed — but only after the application to the bill is undone first.

A payment run pays a batch of approved supplier bills in one sitting, with one person preparing it and a different person approving it before any money leaves. You open Payment runs from the purchasing row of links, or press New payment run on the bills list. The screen lists every approved bill with something owed that is due by the date in Bills due by — a week from today unless you change it — and that is not already in another open run. You name the run, set a pay date and the account to pay from for bank, cheque and cash lines, and tick the bills. Each line starts at what is owed less any open debit notes from that supplier, which are shown under the line and applied when the run is paid; you can lower an amount to pay part of a bill. The method defaults to bank transfer when the supplier has bank details on file, otherwise M-Pesa to their phone.

A run moves from draft to submitted to approved, then processing and completed. Whoever built or submitted it cannot approve it, and the run page says so while it waits. The only exception is a workspace where nobody else holds the approval permission: the preparer may then approve their own run so the feature stays usable, and the audit log records it as approved by its preparer. An approver can send a run back with a reason, which returns it to draft. Approval also records each line’s payment details as they are at that moment, so if a supplier’s bank account or M-Pesa number changes afterwards, that line is refused when the run is paid until an approver retries it to accept the new details. Every line is validated again at approval and again at payment: a bill paid by hand, cancelled or credited in the meantime cannot be overpaid, a bill can sit in only one open run at a time, and Pay now is refused before the run’s pay date.

In practice: on the 24th, the payables officer at a Kampala distributor builds a run for the 25th with three bills — KES 410,000 to a packaging supplier, KES 96,000 to a transporter, and KES 180,000 to a printer who also has an open debit note of KES 30,000. The printer’s line starts at KES 150,000 with the note shown beneath it, so the run total is KES 656,000 in cash. She submits it. The finance manager approves on the 24th, but pressing Pay now that afternoon is refused because the pay date is tomorrow. Overnight the transporter emails new bank details and the officer updates the supplier record; on the 25th that one line is refused when the run is paid, while the other two go through. The finance manager checks the new details with the transporter by phone, presses Retry to accept them, and pays the run again for that line.

A run pays each line by one of six methods. Bank transfer is the one that most often surprises people: pressing Pay now does not record a bank line as paid. It moves to Awaiting bank, and the approver downloads the Bank file — a CSV of beneficiary, bank code, account number, amount, currency, reference and narrative — to upload to the bank’s bulk payment screen. Nothing posts until someone confirms the bank paid, with Confirm all bank payments and the date they were paid; a line the bank did not pay is marked Bank didn’t pay with a reason. Cheque and cash lines are recorded as paid when you press Pay now, from the run’s pay-from account. M-Pesa B2C pays the supplier’s phone, M-Pesa B2B their paybill or till from the supplier record, and Bank Transfer (Paystack) sends to their bank account through Paystack once transfers are set up for your business.

The gateway methods have limits that are enforced, not advised. M-Pesa and Paystack pay in KES only, M-Pesa pays whole shillings, and an M-Pesa B2C line above KES 150,000 is refused so you can split it or pay by bank. Gateway lines show Sent — awaiting confirmation until the provider confirms. When you press Pay now, every pending line is attempted; a line that fails keeps its reason and the rest carry on, and each line is claimed before any money moves so a double-click or two people pressing at once cannot pay it twice. A failed line can be corrected and retried. An M-Pesa timeout is different: it means the outcome is unknown, so the line shows Check with Safaricom and cannot be retried until someone checks the statement and marks it paid or not paid. Every confirmed line is an ordinary supplier payment: it reduces the bill and the order, posts Dr accounts payable, Cr the account it was paid from, and appears under Vendor Payments. The run completes on its own when nothing is still in flight.

In practice: a run of nine lines totalling KES 1.84 million is paid on a Friday. Six bank lines worth KES 1.52 million go to Awaiting bank; the approver uploads the file to the bank portal. Two M-Pesa B2C lines of KES 42,000 and KES 18,500 go out — the first confirms, the second times out and shows Check with Safaricom. One cheque line of KES 64,000 is recorded as paid at once. On Monday the bank statement shows five of the six transfers; the approver confirms those five with Friday’s date and marks the sixth Bank didn’t pay, reason “account closed”. The M-Pesa statement shows the KES 18,500 never left, so it is marked not paid, which makes it a failed line that can be retried. Until those decisions are made the run stays in processing — and the five confirmed bank lines are the only bank payments in the ledger.

Payables begin with buying, and for routine restocking AWRA offers a shorter road than requisition, RFQ and quotation every time. Reorder, in the same row of links, lists every item at or below its reorder point, with its stock, its reorder point, what is already on open orders, and a suggested quantity, supplier and price. An item appears only once it has a reorder point set. The supplier suggested is the item’s preferred supplier, else whoever it was last ordered from; the unit price is the last price paid to that supplier, else the item’s buying price. The quantity is the item’s reorder quantity when it has one, otherwise enough to bring stock up to twice the reorder point — in both cases less what is already on order, so the suggestion is zero when enough is on its way.

With more than one warehouse, Stock in at the top counts stock and open orders for a single warehouse, so a branch that is short shows up even when the total looks fine; a user tied to one warehouse always sees, and orders into, that warehouse. You choose where the goods should arrive and, if you use them, a location. Every value on a row can be changed before anything is created, and every ticked item needs a price above zero, because the order goes to the supplier as soon as it exists. Create and send orders makes one purchase order per supplier and emails each one straight away, landing you on the purchase orders list with their numbers; a supplier with no email address on file is named in a warning, and that order has to be sent by hand. These orders skip quotation approval, so an administrator can cap them with Largest order the Reorder page may send under Settings → Procurement: an order to one supplier above it is refused and has to go through a requisition. Each order is labelled as a direct award, so it is clear it skipped a competitive RFQ, and from then on it behaves like any other order — receiving, the three-way match, the supplier bill and payment. Reorder needs the same permission that creating purchase orders needs.

In practice: a Kisumu agrovet has 14 items at or below their reorder points on Monday morning. A maize seed with a reorder point of 50 bags and 18 on hand, no reorder quantity and nothing on order is suggested at 82 bags (twice 50, less 18). A fertiliser with a reorder quantity of 100 and 40 already on an open order is suggested at 60. A new herbicide shows no supplier because it has never been ordered and has no preferred supplier; the buyer picks one on the row. She unticks two items the branch is discontinuing and presses Create and send orders: five purchase orders go out, one per supplier, each marked as a direct award. When the goods arrive and are checked in, each supplier’s invoice is captured as a bill against its order, prefilled with the quantity received.