AWRA OpsHub Search
Procurement · Accounts payable

Pay the bill that matches — once, and only once.

Capture the supplier’s invoice against the order it bills, or for rent and services with no order at all. Line it up with what was ordered and received, approve it, set returns against it, and pay a whole week’s bills in one run that a second person signs off.

Supplier bills · Returns and debit notes · Payment runs · Reorder to purchase order · Web, API and the mobile app

Oncea supplier’s invoice number can be captured once per supplier, so the same invoice is never paid twice
Order + tolerancethe ceiling on everything billed against one purchase order
Two peopleone prepares a payment run, someone else approves it
6 ways to paybank file, cheque, cash, M-Pesa to a phone, M-Pesa to a paybill or till, Paystack transfer
Why the bill is its own document

A purchase order says what you agreed. The bill says what you owe.

Most payables losses are not fraud. They are the same invoice keyed in twice by two people, a supplier billing for 220 cartons when 200 arrived, a credit for damaged goods that was promised on the phone and never taken, and a payment that went out because the person who prepared it was also the person who approved it.

Each of those has a rule here. A bill is captured once per supplier invoice number. Bills against an order cannot add up to more than the order plus the price tolerance you set. A return raises a debit note that sits against the supplier’s next bill. And a batch of payments needs a second pair of eyes before any money leaves.

Two kinds of bill

They post differently, on purpose.

The difference is when the payable was first booked. Getting this wrong is how a ledger ends up owing a supplier twice what the invoice says.

Against a purchase order

The payable was booked when the goods were received and the check-in was approved, so approving the bill posts nothing to the ledger — a second credit would double what you owe. The bill is the document you pay, and the third leg of the match: its lines are compared with what was ordered and what arrived. Capture it from the order and its lines arrive pre-filled.

On approval
No journal — the receipt already booked the payable
Match result re-run and stored on the order

Without an order

Rent, electricity, a consultant, a courier. Nothing was received into stock, so the bill is where the cost first reaches the books. Each line can carry its own expense account; a line without one falls to the bill’s account, then to operating expenses. Cancel the bill before it is paid and the journal is reversed.

On approval
Dr Expense, per line accountnet
Dr Input taxVAT
Cr Accounts payabletotal
The life of a bill

Captured, approved, paid down, closed.

The balance on a bill is never typed. It is recomputed from the payments and debit notes against it, so the figure on the bill, the order and the payment run always agree.

Draft or submitted

Captured

Your team keys it in, or the supplier submits it from the vendor portal with their invoice file attached. A portal bill arrives as submitted, and everyone who can approve bills is notified.

Approved

Open for payment

Someone holding the approval permission signs it off. An order bill is checked against the order ceiling first; an expense bill posts its journal.

Partly paid

Paid down

Payments and applied debit notes reduce the balance. Each payment posts Dr Accounts payable, Cr the account the money left from.

Paid

Closed

The balance reaches zero and the bill closes itself, and the order it billed shows the same payment.

RejectedSent back with a reason. Correct it and it returns for review — as submitted if it came from the supplier, as a draft if your team captured it.
CancelledOnly while nothing has been paid or credited against it. Reverse those first; an expense bill’s journal is reversed with it.
Worked example

One order, one return, one Friday run.

A Nairobi distributor orders packaging from a Mombasa supplier. Every figure below is what the bill, the debit note and the run would show. Amounts in KES.

1

The order and the receipt

PO-0418: 200 cartons at 1,250, which is 250,000, plus 16% VAT of 40,000 — an order total of 290,000. All 200 are checked in and the receipt is approved, which books the payable.

2

The bill arrives and is approved

Their invoice INV-7731 is captured as BILL-0093 for 290,000, from the order, so the lines pre-fill. Approval posts nothing and re-runs the match. With a 2% price tolerance, bills against this order may total at most 295,800.

A second bill of 10,000 against PO-0418 would bring the total to 300,000 and is refused at approval. Keying INV-7731 for this supplier again is refused at capture, naming BILL-0093.
3

Twelve cartons go back

Twelve arrived crushed. A return of 12 at the order price of 1,250 is 15,000. Approving it takes the stock out and raises a debit note that books Dr Accounts payable, Cr Inventory 15,000. Applied to BILL-0093, the balance falls to 275,000.

Returning 201 cartons against an order that received 200 is refused.
4

Friday’s payment run

The run picks up every approved bill due by Friday: BILL-0093 at 275,000, the office rent BILL-0094 at 87,000 (75,000 plus 12,000 VAT), and a courier bill BILL-0097 at 18,560 (16,000 plus 2,560 VAT). Total 380,560. The accountant who built it submits it; the finance manager approves it and pays it.

BILL-0093, line by line

The balance due is recomputed from what was paid and credited — it is never typed. Below it, the journal each event posts; a dash means it posts nothing, because the payable was already booked when the cartons were received.

Bill total290,000
Debit note applied− 15,000
Paid in PRUN-0012− 275,000
Balance due · Paid0
Bill approved
Debit—
Credit—
Debit note raised
Accounts payable15,000
Inventory15,000
Debit note applied
Debit—
Credit—
Run line paid
Accounts payable275,000
Bank275,000
Run lineSupplierMethodWhat happens when it is paidAmount
BILL-0093Mombasa Packaging LtdBank transferIn the run’s bank file to upload; awaits your confirmation that the bank paid it275,000.00
BILL-0094Westlands office landlordBank transferIn the bank file; awaits confirmation from the bank statement87,000.00
BILL-0097Swift CouriersM-Pesa to a paybillSent through M-Pesa; completes when the confirmation comes back18,560.00
PRUN-0012 total380,560.00
Payment runs

Pay forty bills in one sitting, and still have a second signature.

A run collects the approved bills due on or before a date that are not already in another open run. You choose a method per line and can pay part of a bill. Then it goes draft, submitted, approved, paid — and whoever built or submitted it cannot approve it.

Re-checked at every stepEach line is validated again when the run is approved and again when it is paid. A bill paid by hand, cancelled or credited in the meantime cannot be overpaid.
The one exception, recordedIn a workspace where nobody else holds the approval permission, the preparer may approve their own run so the feature stays usable — and the audit log records it as self-approved.

Bank transfer

Recorded as paid, and gathered into a CSV of beneficiary, bank code, account number, amount, currency, reference and narrative to upload to your bank’s bulk payment screen.

Cheque

Recorded against the bill with its reference, from the account you choose as the source of the run.

Cash

Recorded the same way, for the small supplier paid over the counter.

M-Pesa to a phone

Sent through M-Pesa once payouts are set up. A line above the KES 150,000 a transaction allows is refused with a clear message, so you can split it or pay by bank.

M-Pesa to a paybill or till

For suppliers who are paid at a business number, taken from the supplier record.

Paystack transfer

Sent to the supplier’s bank account through Paystack. A line that fails keeps its reason and can be retried once the details are corrected; the rest of the run carries on.

Returns and debit notes

The credit the supplier promised, taken where it counts.

Goods sent back

A return names the warehouse it leaves from and, against an order, cannot exceed what was received and not already returned. Serial numbers go back with the units. Approving it takes the stock out and raises the debit note in one step.

On approval
Dr Accounts payablevalue returned
Cr Inventoryvalue returned

A price agreed down

A short-delivery credit, a rebate, a price corrected after the fact — a debit note with no goods. It credits Purchases unless you choose the account the cost went to.

Then, either
Applied to one of that supplier’s open billsposts nothing
Refunded by the supplier: Dr Bank, Cr Accounts payableposts
Reorder to purchase order

Low stock becomes an order with the supplier you always use.

Stock bought from the same supplier every month should not need a requisition, an RFQ and a quotation each time. The reorder screen lists every item at or below its reorder point, with what is already on order, a suggested quantity, the supplier and a price — and every one of those can be changed before anything is created.

The supplier is the item’s preferred supplier, else whoever it was last ordered from. The price is the last price paid to that supplier, else the item’s buying price. The quantity tops the item up by its reorder quantity, or to twice its reorder point, less what is already on order.

One purchase order is created per supplier, labelled as a direct award, and from there it behaves like any other order — receiving, matching, bills and payment.

Below reorder pointReview the suggestionOne order per supplierReceiveBillRun
What you get

Controls you would otherwise run on a spreadsheet.

Duplicate invoice check

A supplier’s invoice number is unique to that supplier. Keying it twice is refused and names the bill it already is.

Order ceiling

Approved bills against one order cannot exceed the order total plus the price tolerance in your procurement settings.

Payment match gate

A bill against an order is paid only if the order passes the same match check every supplier payment screen uses. Paying past a discrepancy needs its own permission and a written reason.

Due dates and overdue

A bill is due 30 days after its date unless you say otherwise. The bills list shows what you owe, what is overdue and what is waiting for review, with an overdue-only filter.

The supplier’s invoice attached

Their file stays on the bill and is served only to people with permission to see bills.

Bills from the vendor portal

Suppliers bill the lines of their own orders, attach the invoice, and see when it is approved. Nothing is payable until your team approves it.

Withholding on the bill

A supplier’s default withholding rate carries onto their bills, and the balance due is net of it, so runs pay the net.

Every payment posts

However a bill is paid — by hand, in a run, by a gateway callback — the payment books Dr Accounts payable, Cr the source account, once.

Web, API and mobile

Bills, returns, debit notes, payment runs and reorder all have API routes and screens in the AWRA mobile app.

The straight answer

What AWRA OpsHub does today

  • Supplier bills against a purchase order or without one, with lines pre-filled from the order and an expense account per line on the ones without.
  • Approval by permission, with rejection and a reason, and a corrected bill returning for review.
  • A duplicate check on the supplier’s invoice number, per supplier, at capture.
  • An order ceiling of the order total plus your price tolerance across every approved bill on that order.
  • The three-way match re-run when a bill is approved, with the supplier’s own bill lines as the billed leg.
  • Payment through the same match gate as every other supplier payment, with an override that needs its own permission and a written reason.
  • Ledger posting: an expense bill on approval, every payment once it is confirmed, a debit note when it is raised, a refund when it arrives.
  • Supplier returns that take stock out, carry serial numbers and stop at what was received against the order.
  • Debit notes for returns or price adjustments, applied to an open bill of the same supplier or refunded.
  • Payment runs with maker–checker approval, re-validation on approve and on pay, one open run per bill, a bank CSV and M-Pesa and Paystack payouts.
  • Reorder to purchase order, one order per supplier, with supplier, price and quantity suggested and editable.
  • Bills submitted by suppliers from the vendor portal, with the invoice file required and approvers notified.

More we can add to your workspace

  • A payables aging built from bills — current, 1–30, 31–60, 61–90 and over 90 days by each bill’s own due date. Today the aging report’s payables side ages open purchase orders by their expected delivery.
  • Value-based approval routing for bills, so a bill above an amount you set needs a second or more senior approver.
  • A capture-and-approve split on single bills, so whoever keyed a bill is refused when approving it, as a payment run already does.
  • Recurring bills for rent, service contracts and subscriptions, raised on a schedule.
  • Reading a supplier invoice from a PDF or an email into a draft bill.
  • Early-payment discount terms, with the run suggesting which bills are worth paying early.
  • Bank file layouts per bank, beyond the one general CSV most bulk-payment portals accept.
  • Scheduled reorders, raised on a calendar for review rather than when someone opens the screen.

Where we point you to a specialist

  • We will not let a payment past a failed match quietly. An override exists because real businesses need one, and it carries a separate permission, a written reason, a name and a time.
  • We will not book a second payable for a bill against an order. The receipt booked it. A system that credits payables again on the bill will report you owe twice what you do, and that is the error we designed against.

A bill-based payables aging is the item in that middle column that most changes a month-end, and value-based approval is the one auditors ask about first. Tell us how your organization approves and pays suppliers and we will come back with a written spec, a timeline and a price.

Frequently asked questions

What is the difference between a bill against a purchase order and one without?
A bill against an order is for goods that were received into stock. The payable was booked when the receipt was approved, so approving the bill posts nothing — it is the document you pay and the third leg of the match. A bill without an order is for rent, utilities or services. Nothing came through receiving, so approving it posts the journal: each line’s net to its expense account, the VAT to input tax, and the total to accounts payable.
How does a bill relate to the three-way match?
Once a bill against an order is approved, its lines become the billed leg of the match, compared with what was ordered and what was received, and the result is stored on the order. Before that, the approved bills on an order may not add up to more than the order total plus the price tolerance in your procurement settings. Paying a bill against an order then goes through the same match check every supplier payment uses, so a discrepancy blocks payment unless someone with the override permission records a reason.
Can the same supplier invoice be paid twice?
A supplier’s invoice number can be captured once per supplier. Keying it again is refused at capture and names the bill it was already captured as. A bill can also sit in only one open payment run at a time, and each run line is re-checked when the run is approved and again when it is paid, so a bill paid by hand in the meantime cannot be overpaid.
Who can approve a payment run?
Anyone holding the payment-run approval permission except the person who built or submitted it. The one exception is a workspace where nobody else holds that permission: the preparer may then approve their own run so the feature stays usable, and the audit log records that approval as self-approved.
Which payment methods can a run use?
Six, chosen per line: cheque and cash are recorded as paid; bank transfers are gathered into a CSV to upload to your bank’s bulk payment screen and wait under Awaiting bank until someone confirms the bank paid them (or marks a line rejected), so nothing is posted for money that has not left; M-Pesa to a phone, M-Pesa to a paybill or till, and Paystack transfers are sent through their gateways and complete when the confirmation arrives. A failed line keeps its reason and can be retried while the rest of the run carries on.
How do returns and debit notes reduce what we owe?
Approving a return takes the goods out of stock and raises a debit note that books the value returned against accounts payable and inventory. You then apply the note to one of that supplier’s open bills, which lowers the balance due without posting again, or record the supplier refunding it. A debit note with no goods, such as a price agreed down, credits Purchases unless you choose another account.
How does reorder decide the supplier, price and quantity?
It lists items at or below their reorder point. The supplier is the item’s preferred supplier, else the one it was last ordered from; the price is the last price paid to that supplier, else the item’s buying price; the quantity tops up by the reorder quantity, or to twice the reorder point, less what is already on order. You can change any of it before one purchase order per supplier is created.
Can bills be aged by due date?
Every bill carries a due date — 30 days after the bill date unless you set one — and the bills list shows what you owe, what is overdue and what is waiting for review, with an overdue-only filter. The aging report’s payables buckets currently age open purchase orders by their expected delivery; a payables aging built from bill due dates is something we can add to your workspace.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center