The Payment Picked at Random

The auditor has the year’s bank statement open and a ruler under the March page. She stops at a transfer of 18,400 to a printing supplier on the fourteenth and turns the page round. “This one. Show me the request it came from, who approved it and at what level, which quotes you compared and why this one won, the order, the delivery, the invoice, the match and whoever released the money. And then I’ll want to see that no one person did two of those things they shouldn’t have.”

It is the most ordinary test in a procurement audit and the most revealing, because nobody chose the payment for you. A team that reassembles the story from email, a shared drive and somebody’s memory fails it slowly, in front of the person writing the management letter.

This post walks one payment back through AWRA the way the auditor will: what each record shows, whom it names, what cannot be changed afterwards, and where the trail is thin — offered as things we can add — with a checklist to run before fieldwork.

What she is actually testing

The bank has already proved the money left. The auditor is testing two other things, and it helps to know which is which before she sits down.

• Authorisation. That every step your policy describes happened, in order, by someone entitled to do it — from the need being raised to the money being released.
• Separation. That the steps were done by different people where your policy says they must be. The classic incompatible pairs are requesting and approving, ordering and receiving, keying an invoice and approving it, and approving an invoice and paying it. The segregation of duties post sets out why each pair matters.

The first test is about documents and their links. The second is about comparing names across documents, which most systems leave to the auditor.

Eight stops, walking backwards

In AWRA each procurement document is linked to the one it came from, so the walk is a series of clicks rather than a search.

1. The payment

   A supplier payment is recorded against a supplier bill and its purchase order, with the method, the reference, the date and the person who recorded it. If it went out in a payment run, the run holds who prepared it, who submitted it and who approved it, and the supplier’s bank details exactly as they stood when the run was approved.

2. The supplier bill

   The bill links to its purchase order. Its match card compares what was ordered, received and billed inside your tolerances, and lists every payment and debit note against it.

3. The purchase order

   The order links to its quotation and the quotation request behind that. Its order trail lists who created it, the goods receipt and who raised it, and each payment with who recorded it. Any authorised override of a failed match carries the authoriser’s name and written reason.

4. The goods receipt

   The check-in that booked the delivery into stock records who submitted it, who approved it and who posted it, with a signature name and time when one was taken at the door. A service is received by a delivery confirmation instead, which counts in the match the same way.

5. The award

   Where an approval rule applied, the winning quotation’s panel shows the rule, the amount it was judged at, and each step with who signed and when. The other open quotes on the request were marked rejected in the same action.

6. The comparison

   The quotation request lists every quote received, ranked on price, delivery time, distance and supplier score by your workspace’s weights, with the top-ranked quote flagged. A sealed request refuses any award until its bids are opened after closing, and an expired quote cannot be awarded.

7. The requisition

   The quotation request links back to the procurement request that started it. That page shows its status trail — submitted by, approved by, or rejected by — and its own approval panel when a rule applied.

8. The audit log

   Every change made through the browser, the supplier portal or the mobile app is in the audit log with the person, time and network address — searchable by record number, filterable by module, person and dates, and exportable.

Two practical notes. The purchase order reaches the requisition through the quotation request rather than directly. And the bill and payment-run pages do not print who entered, approved and prepared them: those names are held on the record and in the audit log, where a search on the bill or run number finds them.

At what threshold: the question about rules

“Who approved it and at what level” has two possible answers in AWRA, and the auditor needs to know which one your organization chose before she reads a single panel.

If your workspace has approval rules — set under Settings, Approval Rules, by document type, amount band and optionally department — then a requisition, an award or a supplier bill above a band needs each step in its chain signed, in order. The panel shows the rule’s name and the amount it was judged at, so “why did this need two signatures and not three” is answered on the page. A document that changes after someone signed starts its approval again, so no signature carries onto a version its signer never saw. Cover is shown as signing on behalf of the absent approver — see done, according to whom.

If your workspace has no rules, approval is decided by permission: anyone holding the approval permission approves, at any amount, and the record and audit log name them. That is a legitimate design for a small team, but it is a different control from a value-based chain, and your written procurement policy should say which one you run. The auditor will test the system against the policy, not against what she assumes.

Why this one won

This is the stop where most trails, ours included, are thinnest. AWRA keeps the competition: every quote received, the closing time, the opening of sealed bids, the ranking flag on the top quote and, where your organization uses AI summaries, a plain-language explanation of the ranking stored on the quotation request with the time it was written.

Two things the auditor may ask for are not kept as records. The individual scores and the weights used are recalculated when the comparison is viewed rather than frozen at the moment of award, so a change to your weights later changes the picture. And there is no field for the reason a quote won. If the top-ranked quote was awarded, the ranking is the reason. If someone chose a different supplier — which in AWRA is done through the line-by-line award on the quotation request — the reason lives wherever they wrote it down. The evaluation that happens in a spreadsheet covers why that matters for a scored tender.

A ranking explains the winner when the winner was ranked first. When it was not, only a sentence written at the time will do.

The match, and the payment gate behind it

Every route that pays a supplier in AWRA — a single payment, a payment run, a manual record, a mobile-money transfer — passes one gate that re-runs the match before money moves. A discrepancy between what was ordered, received and billed blocks payment by default. Payment before anything is received is allowed and flagged as a prepayment, unless your organization has switched that to a refusal.

Paying past a failed match needs its own permission, separate from approving orders, and a written reason. The authorisation is pinned to the exact discrepancy it was granted for. If the documents change, it is withdrawn rather than left to cover a different problem. That withdrawal clears it from the order page, but both the grant and the withdrawal stay in the order’s audit history with who, when and the reason. The tolerances themselves, and why they ship at zero, are in every tolerance ships at zero.

Who did what: reading the names against each other

Now the second test. AWRA enforces separation inside each document: the person who raised or entered something is refused when they try to approve it. What it does not yet do is compare names across the documents of one chain. This is the honest shape of it.

The two columns answer different questions. “Refused on the document” is a hard stop at the moment of approval. Access Conflicts, under Settings, lists every person and role holding a dangerous pair of permissions — raising and approving orders, keying and approving bills, creating a supplier and approving its bills, building and approving payment runs — so you can show the auditor who could combine duties, and what compensating check you rely on where they can. The bill rule itself is explained in the person who keys the bill cannot approve it.

Neither column gives her this payment’s answer: the names at all eight stops side by side, with any repeat highlighted. Today someone builds that table from the pages above and the audit log — ten minutes for one payment, most of a day for a sample of thirty.

What nobody can quietly change afterwards

An auditor relies on a record only as far as she can rule out its being tidied before she arrived.

• Signatures follow the document. A requisition, award or bill that changes after it was signed loses those signatures and starts its approval again. The superseded chain is kept, not deleted.
• Quotations are kept. A quotation cannot be deleted; it can be rejected or its order cancelled, and the history stays.
• Orders change through revisions. A change to a purchase order is proposed, approved by someone other than the proposer, checked against the budget when it adds to the spend, and re-sent to the supplier.
• Payment details are fixed at approval. If a supplier’s bank details change after a payment run is approved, that line refuses to pay until an approver looks at the change.
• The audit log is permanent and verifiable. Entries cannot be deleted by an administrator, each is chained to the one before, and anyone with settings rights can run a verification that is itself recorded. An audit trail nobody can delete explains the chain; the audit trail that leaves the building covers copying it to a store your security team controls.

Before the auditor arrives

Frequently asked questions