Purchasing and Supplier Automation: From Request to Invoice

Purchasing tends to be the last major company process still running on email and trust. An order is agreed over the phone, the confirmation lands in one person's inbox, the goods are received by whoever happens to be in the warehouse, and the invoice reaches accounting three weeks later. While the company has fifteen people, this works surprisingly well — the owner sees practically every expense and remembers it. At fifty people and hundreds of orders a month it turns into a black hole: the accountant keeps in her head what was approved, the warehouse does not know what is coming, and controlling discovers the budget overrun only after month-end close.

Purchasing automation does not mean replacing the buyer with software. It means giving the request-to-payment chain a shape in which it is clear at any moment who asked for what, who approved it, what was actually delivered and whether the invoice matches. Most of the savings do not come from better negotiation but from the company no longer paying for things it never ordered, twice for the same delivery, or outside agreed price lists.

Take your last hundred invoices and try to find the matching purchase order for each. The share you cannot match is the cheapest purchasing diagnostic you can run in a single afternoon.

You will typically find three kinds of leak. The first is informal requests. A colleague writes in chat "order me two more monitors", the buyer orders them, and there is no record of who asked, for which cost centre, or from whose budget. Six months later, when someone asks why IT overspent, there is nobody to ask.

The second is a missing approval trail. The approval happens verbally or as an "ok" reply in an email that cannot be attached to the document. Formally everything is fine; practically there is nothing to produce for an audit or an internal review.

The third is buying outside contracts, known as maverick buying. The company has a negotiated framework with a supplier, but a branch orders the same thing elsewhere because it was faster. The volume the discount rests on gets fragmented, and at renewal the company finds it has nothing to argue with.

Purchasing that cannot be reconstructed from documents after the fact is not a process — it is a habit shared by a few people.

The common denominator of all three is that the request never had a record of its own. Everything else in purchasing hangs on exactly that.

The first step is boring and irreplaceable: a purchase request must be an object in a system, not a message. The minimum content is what, how much, for whom, for which cost centre or project, by when, and an estimated price. For recurring items most of this can be filled from a catalogue, so the requester fills in two fields instead of eight.

Only on top of such a request does approval make sense. The rules are usually a combination of amount, category and cost centre — which is exactly why they should not be hard-coded but kept in a configurable matrix the CFO can change without a developer. The mechanics are the same as for other approval processes in a company: defined roles, limits, delegation during holidays, and escalation once a deadline passes.

The figures in the table are illustrative — what matters is the structure, not the specific thresholds. More useful than generous limits is usually the rule that without an approved request no order can be issued at all. A system that allows itself to be bypassed will be bypassed.

When choosing which processes to bind with rules first, a simple logic applies: start where the volume is high, the rules are unambiguous and mistakes are expensive.

This is the part most companies underestimate, and then wonder why nothing works. A supplier master record is not "name and company number". It is the identity that orders, contracts, price lists, invoices, payment details and complaint history all attach to.

Why duplicates break everything downstream

If the same supplier exists three times in the system — once with diacritics, once with "Ltd.", once with a typo — four things stop working at once. Volume reporting shows three small supplier relationships instead of one large one, so the company loses its negotiating position. Contract price checks attach to the wrong record and let through a price outside the price list. Invoice matching fails because the invoice arrives under a different company number than the order. And limit controls can be bypassed by splitting an order between two "different" records.

The practical minimum worth introducing before any automation:

• A single owner of the supplier register. New suppliers are created by a designated role, not by whoever happens to be ordering.
• Duplicate checking at creation based on company number and IBAN, not on name.
• Verification against public registers — the commercial register, VAT payer status, and where applicable lists of unreliable taxpayers.
• A special regime for bank account changes. This is the single most common fraud vector; more on it below.
• Regular review of inactive records, so the register does not keep companies you have not traded with in five years.

If supplier data lives simultaneously in the ERP, in accounting and in the e-shop, deal with system integration of ERP, CRM and other systems before automation — otherwise you will be automating three mutually contradictory versions of the truth.

Three-way matching is the oldest and still the most effective control in purchasing. The system compares three documents — what we ordered, what we actually received and what we are being invoiced for — and releases for payment only what agrees on all three.

The key decision is not technical but political: which deviations are you willing to release automatically. Tolerances that are too tight mean half the invoices end up in a manual queue and people start working around the matching. Tolerances that are too loose mean the control does not control anything.

For matching to run at all, invoices must be in structured form. Machine reading of documents already serves well here — we covered the principles and the limits in the piece on an AI agent for processing invoices and accounting documents. The essential point is that data extraction and the decision to pay are two different things: the first can be delegated to a model, the second should stay with rules and a human.

Goods receipt is the weakest link here if the warehouse does not record the receipt at the moment of delivery. Without a trustworthy delivery note, three-way matching becomes two-way matching, which is a noticeably weaker control. Companies handling stock separately will benefit from linking this to warehouse and inventory management automation.

Expiry alerts

Contracts and price lists have validity dates, but nobody tracks them until something goes wrong. Automation has one of its best returns here precisely because the function is trivial: every contract and price list carries a validity date, a notice period and an owner, and the system alerts the responsible person well in advance — typically in three waves, for example 90, 30 and 7 days before the end.

The point is not only that the contract does not lapse. It is that renewal talks can start while the company still has leverage — not three days before expiry, when the only option is to sign whatever arrives.

Performance tracking

Once orders and goods receipts exist as data, supplier scoring is largely a derived calculation. Two metrics cover most practical needs: on-time delivery (share of deliveries within the promised date and average delay in days) and quality (share of claimed or defective items). It is worth adding the share of invoices that failed matching on the first attempt — a good indicator of a partner's administrative reliability.

Three notes from practice. First, scoring only makes sense with enough deliveries; at three orders a year it is noise. Second, the "date" measured must be the supplier's confirmed date, not the requester's wish. Third, the score is not there to disqualify suppliers automatically but to inform negotiation. A number nobody uses in a conversation with the other side is just another chart on a dashboard.

Colleagues see approval steps as bureaucracy until an incident happens. Yet the strongest argument for them is not budget discipline but separation of powers: the same person should not be able to create a supplier, approve an order, confirm receipt and release payment. Not because they are suspicious, but because that combination of rights is an opportunity that sooner or later finds someone — and it also fails to protect the employee from suspicion.

The most common scenarios that rules can cover:

• A fictitious supplier with correct-looking documents — countered by separating supplier creation from order approval.
• A bank account change requested by email. A classic: a message arrives from a lookalike domain asking to change the IBAN. The rule must be that account changes are confirmed by calling back a known number, never by replying to the received email.
• Splitting an order below the approval limit — the system can flag multiple orders to the same supplier within a short window.
• Back-dating orders against invoices already received, which masks purchases made outside the process.

Most of these risks are organisational rather than technical. Software can make them visible and harder to execute but cannot remove them — and with email-based fraud it is worth looking at the wider context of corporate protection against cyber threats.

Let us be specific about what this approach does not solve.

Automation will not replace a purchasing policy that does not exist. If the company has never agreed who may order what, when three quotes are required and what counts as capex, the system will simply repeat those undefined decisions faster. The first week of a project is therefore usually about writing rules, not configuring software.

It will not help where the volume is too small either. A company with twenty orders a month handled by one person gets less value from a structured process than it costs to maintain. Even there, though, a clean supplier register and duplicate invoice checking are worth having.

Finally, automation will not fix supplier relationships. A reliability score does not replace a phone call when a delivery is late, and no system will tell you your key partner is in financial trouble — you will learn that from a conversation sooner than from a report.

Purchasing automation rests on four pillars, best built in this order: clean supplier master data, a structured request, approval by written rules, and three-way matching before payment. On top of that you can stack contract expiry tracking, supplier scoring and fraud controls.

The first step is cheap and requires no new software: take the last hundred incoming invoices and find out how many have a traceable order and approval. That share will tell you more about the state of your purchasing than any presentation. If you then want to move from diagnosis to a solution shaped around your process, get in touch and we will walk through your purchasing chain from request to payment.