AP invoice control

Check PO and non-PO invoices before payment

• Domain: Finance & Accounting
• Moment: Before the money moves
• Customer: An e-money and wallet operator

Check PO and non-PO invoices through the right process.

The situation

An accounts payable team receives supplier invoices by email and by upload. Some carry a purchase order. Many do not: professional fees, cloud and telco, agency retainers, licence renewals, courier, utilities. Both land in the same queue, with the same people, against the same deadline.

A clerk opens the file, finds the supplier in the master, keys the header and lines, compares them on screen to the purchase order and receipt where one exists, then picks a tax code, a withholding category, a cost centre and a pay group.

Every step is a judgement made from memory, at speed, by someone who will not find the error.

What breaks today

Supplier matching relies on names. One legal entity may appear several times in the master with a branch suffix, trading name, or typo. The wrong match can apply incorrect payment terms or bank details.

Non-PO invoices need a policy check. With no order or receipt, the team must use the approved commitment, contract or rate schedule, and approval matrix.

A consumed purchase order gets consumed twice. Partial deliveries produce several invoices against one PO line. The running balance lives in a spreadsheet beside the ERP, so the second is caught only if somebody remembers the first.

Withholding is decided per invoice. Service or goods, the rate for that service type, whether the supplier is a company or an individual, and what to do when one invoice carries both. Wrong rates surface at filing.

The same invoice arrives twice. Once from the supplier, once forwarded by the requester who wants it paid. Different filenames, same document.

What Manuel does

Intake and separation. Documents are pulled from the shared mailbox and upload folder. One attachment may hold several invoices, and one invoice may span several pages. Manuel splits each invoice and reads the layout in context.

Supplier resolution. Tax identifier first, branch code second, name as a fallback, returning the supplier record, its payment terms and bank account. An unresolved supplier becomes an exception listing the candidates and why each was rejected.

Routing based on the available records. PO-backed invoices take the three-way path. Non-PO invoices use the contract or rate schedule, approved commitment, and approval matrix. The result is recorded for later review.

Three-way matching. Line by line against the order and the receipt: quantity, unit price, unit of measure, currency, and the amount already invoiced against that PO line, so a later invoice cannot re-consume it. Tolerance is defined per variance type, so the same variance is treated the same way on Monday and on Thursday.

Tax and withholding as rules. VAT treatment, withholding category and rate by service type and supplier type, split where one invoice carries both. The rule version that ran is retained, so the treatment can be explained later.

Duplicate detection. On invoice number with tax identifier, on amount inside a date window, and on the document itself, so a rescan does not become a second invoice.

Output. Clean invoices produce an ERP-ready posting file with supplier, tax codes, withholding and cost allocation resolved. Mismatches are held as named exceptions: the line, the field, the value expected, the value invoiced and the document checked against.

Before this build was scoped, we ran the control across the customer's own invoices, in their real formats. What it caught is documented and belongs to them. The order is the point: the control was tested on real documents before the scope was written.

What the customer gets

The clerk stops keying and starts deciding. What reaches a person is the set of invoices that need judgement, each with the mismatch named and the document attached.

Duplicates and over-consumed purchase orders are caught before payment. Withholding is applied by a versioned rule. Supplier matching can also reveal duplicate master records.

There is no published before-and-after figure for this control yet. Discovery measures PO and non-PO volume, time per invoice, exception rate by type, and duplicate supplier records per tax identifier.

What stays with your existing systems

The ERP stays the system of record. Manuel does not hold the supplier master, the chart of accounts or the purchase orders. It reads them. Approval authority stays where it is today. Payment execution stays in the banking channel.

The first deployment produces a file the ERP imports through its own path. Write-back is closed later, once permissions and maker-checker are defined.

What a first scope looks like

One entity. One population, usually the non-PO one, because that is the one with no existing control. A historical set of invoices, files first, read-only, output to a file.

We show what would have been held on invoices you have already paid. Acceptance criteria use your own documents.

Related: Enterprise data intake / Job margin protection / Settlement and fee integrity