Procure-to-pay connects a need to a disbursement through five steps: request, approval, order, receipt and payment. It automates well because the rules are explicit, and it fails when the visible part is automated — capturing the invoice — without touching the part that actually consumes time, which is approval.
Below: where the cycle really stalls, what to automate and in what order, the three-way exception, what e-invoicing changes, and how to measure without inflating.
Measure the total time between somebody needing something and the supplier receiving their money, and the result surprises almost every organisation. Effective work rarely explains more than a small fraction of that total. The rest is waiting.
That distinction decides where to invest. A project that speeds up invoice capture improves a stretch that perhaps consumed minutes, while the file still waits days in somebody's inbox for approval. The process ends up just as slow, with a new tool to justify.
Where the cycle really stalls
The five steps do not weigh the same. The request is usually quick where a catalogue exists and slow where every purchase is described in free text, because then somebody has to interpret it before anything can proceed.
Approval is where most of the elapsed time goes. Not because approving is difficult, but because the file arrives by email to somebody who is doing something else, and nothing reminds them or escalates it if nobody picks it up.
The order and receipt are mechanical when the supplier is registered and problematic when they are not: onboarding a new supplier usually requires documents, validations and an extra approval nobody counted when estimating the timeline.
Payment depends on the accounting close and the treasury schedule, and there the delay is usually a decision rather than a friction — worth not confusing the two when measuring.
What to automate, and in what order
The order that pays starts with approval routing, not with document capture. Having the file reach the right person by amount and category on its own, remind if nobody took it, and escalate after a defined interval, cuts total elapsed time more than any other single intervention.
Then prior validation: checking that the supplier exists and is current, that the category maps to a live budget, and that the amount fits policy. These are explicit rules, and catching the problem at the start avoids a file travelling through three approvals before bouncing.
Document capture comes third. It is the most advertised and returns the least time, because data from an electronic invoice already arrives structured and there is nothing to transcribe.
And last the three-way match — order, receipt and invoice — which is pure comparison work and automates cleanly once the three documents exist reliably.
The three-way exception, where the work lives
When the three documents agree there is nothing to do, and the automation resolves it without intervention. The value is in what does not agree, and the discrepancies follow a recognisable pattern.
A quantity difference — a hundred ordered, ninety-eight delivered — usually has an agreed tolerance, and below it nothing should stop. A price difference is more delicate, because it may reflect a commercial agreement that never reached the system. And a missing receipt — there is an invoice and nobody recorded the goods arriving — is almost always a process problem in the warehouse rather than in accounting.
A mature design classifies the discrepancy and routes it to whoever can resolve it, rather than returning the whole file to accounts payable. That distinction is the difference between reducing work and relocating it.
What e-invoicing changes
In Colombia and Mexico the document arrives structured and validated by the authority before the organisation receives it, and that changes the design substantially: the step of "transcribing the invoice" simply does not exist.
What does exist is the opposite problem. Because invoices arrive continuously and on their own, supplier documents accumulate that nobody was expecting, with no purchase order attached. That unauthorised flow is one of the largest consumers of time in accounts payable across the region, and no tool resolves it without a policy on what to do with it.
The useful automation here is not capture but matching and routing: finding the order it belongs to and, where none exists, directing the document to whoever could have raised it instead of leaving it in a shared inbox.
The supplier is part of the process, and that is designed
A good share of delays do not happen inside the organisation. An out-of-date bank detail, an expired tax document or a badly referenced invoice generate email cycles that consume days and appear in no internal indicator.
A portal where suppliers maintain their own details and check the status of their documents removes most of that traffic. It also reduces a real category of risk: a bank account change requested by email is one of the most frequent fraud vectors in the region, and an authenticated channel with second-factor verification mitigates it considerably better than the good judgement of whoever opens the message.
That decision belongs as much to automation as to cybersecurity, and is worth taking jointly.
How to measure without inflating the result
The most quoted metric is cost per invoice processed, and it is the easiest to manipulate depending on what is included. Three hold up in front of finance: total cycle time from request to payment, share of files advancing without intervention, and share of invoices with no purchase order.
The third is the most revealing and the least measured. It describes how much buying happens outside the process, which is a governance problem before an automation one: automating an unauthorised flow makes it more efficient without making it correct.
The return is calculated with local costs. An hour of administrative work saved is not worth the same in Bogotá, in Mexico City, or at a European head office, and using a foreign case study's figure distorts the priority of the entire portfolio.
What is needed before starting
Four figures size the whole case: monthly invoice volume, the share arriving without a purchase order, average approval cycle time, and how many people touch a typical file.
The fourth is usually what convinces. When it is counted, it is common to discover that a low-value file passes through more hands than a large one, because the approval policy grew by accumulation and nobody revisited it. Approval thresholds tend to be set once and inherited, so inflation quietly drags routine purchases into a tier designed for exceptional ones.
A process automation assessment establishes those figures and evaluates the feasibility of each stretch before recommending any. If the diagnosis shows the approval policy is the problem, the right recommendation is to simplify it before automating: automating a seven-approval circuit produces a fast seven-approval circuit.
Frequently asked questions
Which part of the purchasing cycle should be automated first?
Approval routing. That is where most elapsed time accumulates, because the file waits in somebody inbox with nothing to remind or escalate. It cuts the total cycle more than document capture does.
Is it worth automating invoice capture if invoices are already electronic?
Little, because the data already arrives structured and there is nothing to transcribe. The problem e-invoicing does create is a continuous flow of documents with no purchase order, and that is solved by matching and routing rather than capture.
What is the three-way match?
Comparing the purchase order, the goods receipt and the invoice to confirm they agree on quantity and price. Where the three reconcile there is no work; the value is in classifying the discrepancy and routing it to whoever can resolve it.
What tolerances should be defined?
At least one for quantity and one for price, below which the file does not stop. Without explicit tolerances, irrelevant differences consume the same effort as important ones and the automation stops saving anything.
How do you know whether it worked?
Total cycle time from request to payment, share of files advancing without intervention, and share of invoices with no purchase order. The third is the most revealing: it describes how much buying happens outside the process.
Why involve suppliers in the design?
Because much of the delay happens outside the organisation: out-of-date bank details, expired documents, badly referenced invoices. An authenticated channel also mitigates the bank-account-change fraud that arrives by email.
