Automating purchase orders end to end

The purchase order is where a company either controls its spend or loses track of it. Automating it end to end turns a requisition into a coded, approved, budget-checked commitment without anyone retyping, then holds that commitment as the reference every downstream invoice and receipt matches against. Get the PO right and accounts payable becomes arithmetic; get it wrong and every problem surfaces later, at the worst time.

Most procure-to-pay pain is not in the invoice. It is upstream, in a requisition that was coded to the wrong cost center, approved by someone without authority, or raised against a vendor that already exists three times in the master under slightly different names. By the time that error reaches AP, the money is committed and the fix is a manual reclass. So the work starts at intake.

The requisition is where coding gets decided

A requisition arrives as free text, a punchout basket, an email, sometimes a photo of a quote. The job at intake is to turn that into structured lines a system can reason about: what is being bought, from whom, against which budget, under which tax treatment. This is an extraction and classification problem, and the accuracy target is set by what a wrong answer costs downstream.

• Line-item extraction pulls quantity, unit price, description and any quoted vendor SKU from whatever format came in.
• GL account, cost center and project code get predicted from the line description plus the requester’s department and historical coding for similar buys.
• Tax treatment is derived from vendor jurisdiction and item category, because a reverse-charge line coded as domestic VAT breaks your return, not just your ledger.

We treat coding as a model with an eval set, not a lookup table. The eval set is drawn from historically posted POs where the final, corrected coding is known, and we measure per-field accuracy against that. The point-in-time discipline matters here: when you build the training or evaluation data, you use the vendor master and budget state as they were on the requisition date, not as they are today. Otherwise you leak future corrections back into the model and it looks far better in testing than it will in production.

For anything the model is unsure of, it should not guess. A confidence threshold routes low-certainty lines to a human with the prediction pre-filled, so the person is confirming or correcting rather than coding from scratch. That keeps the false-positive budget explicit: you decide how many miscoded lines you are willing to let through automatically, and you tune the threshold to hit it.

Approval routing is a policy engine, not a model

Approval is where automation goes wrong most often, because it is tempting to let the model decide. Do not. The model prepares the decision; a deterministic policy engine makes it. Approval authority, segregation of duties and delegation are rules you can state precisely, and they need to produce the same answer every time and survive an audit.

The routing logic reads the coded requisition and resolves:

• Which approval limits apply, based on amount, category and cost center.
• Whether the requester and approver are different people, and whether the approver actually holds authority for that budget line.
• What additional gates fire above certain thresholds, such as a second signature, a sourcing check, or a capex committee.

Every routing decision writes an audit trail with lineage back to the rule that fired and the requisition state at that moment. When an auditor asks why a 40,000 EUR order skipped the second approver, you answer with a record, not a reconstruction. The model contributes by enriching the requisition so the rules have clean inputs, and by flagging patterns worth a human look, like a series of orders sitting just under an approval limit. Splitting spend to dodge a threshold is a control the policy engine should surface, and it can only do that if the coding upstream was right.

Matching closes the loop, and it depends on the PO being clean

Once a PO is issued it becomes the anchor for three-way matching: PO against goods receipt against invoice. The quality of that match is decided upstream. If the PO lines are well structured and coded, matching is close to straight-through. If they are vague, every invoice becomes a manual investigation.

• Quantity and price tolerances are defined per category, so a small freight variance clears automatically while a doubled quantity stops.
• Partial receipts and partial invoices reconcile against the open PO balance, so a three-shipment order does not throw three exceptions.
• Entity resolution links the invoice’s vendor to the PO’s vendor even when the remittance name differs from the ordering name, which is routine with factored or group-billed suppliers.

Matching also feeds accruals. At quarter-end, an open PO with a booked receipt and no invoice is a known liability, and you can accrue it to the cent rather than estimating. That holds only if the receipt was captured against the right PO line. The cleaner the front end, the smaller the manual close.

What we watch after it goes live

Automation is not done at launch. Coding models drift as the business changes: new vendors, new categories, a reorganization that moves cost centers. We monitor per-field coding accuracy against a rolling sample of human-corrected POs, and we watch the exception rate on matching as a leading signal that something upstream has shifted. A rising match-exception rate usually means requisition coding degraded weeks earlier.

The habit that keeps this healthy is treating every human correction as a labeled example. When someone overrides a predicted cost center, that override goes back into the eval set. Over time you loosen the routing threshold in categories where accuracy holds and tighten it where it slips, so the system takes on more autonomy exactly where the evidence supports it.