Automation Removes the Keying. It Also Removes the Glance.
Automation removes the keying. It also removes the glance that came free with the keying — and unless a rule replaces it, the control you thought you had was a side effect of the work you just eliminated.
There is a control in most growing businesses that nobody designed, nobody documented and nobody would defend if you named it out loud. It is this: somebody has to type the invoice in, and while they are typing it they notice things.
They notice that the price looks high. They notice that the quantity is not what the yard mentioned. They notice that they have never heard of this supplier. It is a terrible control — inconsistent, undocumented, dependent on one person's mood and attention — and in a great many businesses it is the only one standing between a wrong invoice and a payment run.
Structured electronic invoicing removes the typing. That is its entire point and it is a genuine improvement. But if nothing is designed to replace the glance, the net effect is not a faster correct payment. It is a faster wrong one.
The three documents, and why two of them usually do not exist
A three-way match compares three records of the same event. Everybody knows the definition. What is worth being honest about is how often all three actually exist in a form that can be compared.
| The document | What it establishes | Where it usually is |
|---|---|---|
| The purchase order | What we agreed to buy, how much of it, and at what price | Often an email, a WhatsApp message, or a conversation |
| The goods receipt | What actually arrived, in what quantity, in what condition | A signature on a delivery note in a folder at the gate |
| The supplier invoice | What they say we owe | Arriving reliably, in triplicate, chased weekly |
Notice the asymmetry. The one document that is always present, always legible and always on time is the one written by the party who benefits from it. The two that constrain it are the two that get improvised.
The invoice is never the missing document. If your match is failing, it is failing on the two records you were supposed to create yourself.
What the match is actually protecting you from
It helps to be specific rather than to talk about controls in the abstract. There are four leaks, they are all mundane, and none of them involves anybody behaving dishonestly.
-
Price drift
A price was agreed in March. It is invoiced in June at the current list. The difference is four per cent, entirely defensible from the supplier's side, and invisible to the person approving payment because they have never seen the March number. Repeated across a purchase ledger it is the single largest quiet leak in most operations.
-
Short delivery, full invoice
Twenty-four cartons ordered, twenty-four invoiced, twenty-three received. Somebody at the gate noticed and mentioned it. The credit note is owed and will never be asked for, because the receipt record and the invoice never met.
-
The duplicate
A statement chase, a re-sent copy, a slightly different reference. Paid twice. This one is recoverable and embarrassing, and it is found by the supplier roughly half the time.
-
The purchase nobody authorised
Not fraud, usually. Somebody urgently needed something and got it, at a value they were not permitted to commit. The question is never asked at approval time because the invoice does not raise it, and it surfaces annually in an audit sample if at all.
The number that settles the argument
Take one month of purchase invoices. Count how many have a purchase order behind them that carries the agreed price. Not "we usually raise orders" — count. Most operators guess ten to fifteen per cent are missing and find something between a third and a half. Whatever your number is, it is the ceiling on how much any matching system can do for you, and it is a process problem rather than a software one.
Tolerance is the setting that decides whether this works
A match with no tolerance stops everything and gets switched off within a fortnight. A match with a generous tolerance passes everything and is decoration. The useful configuration is narrower than people expect and it needs two dimensions rather than one.
- A percentage and an absolute floor. Two per cent of a large consignment is real money; two per cent of a box of fittings is not worth an exception. Without a floor you will drown in trivia and stop reading the queue.
- Different tolerances for price and quantity. A quantity difference is a fact — it either arrived or it did not, and the tolerance should be near zero. A price difference is a negotiation, and a small one may be genuinely acceptable.
- A rule about what happens to an exception. This is the part that gets skipped. An exception that is merely flagged is an exception that is approved by whoever is in a hurry. An exception that is held requires a decision from somebody named.
- A tolerance you set, not one the vendor chose. Defaults are written to make demonstrations look calm.
Where the receipt actually has to happen
The goods receipt is the record that fails most often, and the reason is almost never negligence. It is geography. Goods arrive at a gate, a yard, a site or a van — places with a person holding a clipboard and frequently no signal — and the system that would record it lives on a desk in an office somewhere else.
So the delivery note goes in a folder, travels to the office at the end of the week, and is entered by somebody who was not there. At that point it is no longer a record of what arrived. It is a transcription of what the supplier said arrived, which is the document you already had.
A receipt has to be capturable where the goods land, by the person who took them, working offline, or it is not a control.
What a working purchase-to-pay chain looks like
- A requisition with an approval that refuses above a threshold rather than warning and letting it through.
- A purchase order carrying the agreed price and quantity — the reference point everything else is measured against.
- A goods receipt taken at the point of delivery, against the order, by the person who received it, offline if necessary.
- A match across all three, with separate price and quantity tolerances and an absolute floor.
- An exception queue that holds rather than warns, with a named owner and a target age.
- A landed cost allocation, so freight and clearance reach the unit rather than an overhead line.
- The supplier's documents attached to the transaction, with registration and licence expiry dates watched by the system.
The order this has to happen in
This is the practical point of the whole piece. Businesses facing an e-invoicing mandate almost always sequence it backwards, because the deadline is on the invoicing and not on the discipline.
The common order
- Appoint a provider and connect the outbound flow, because that is what the deadline is about.
- Switch on the inbound flow because it comes in the box.
- Discover that inbound invoices land somewhere nobody works.
- Discover that there is nothing to match them against.
- Conclude that the software was disappointing.
The order that works
- Measure how many purchase invoices have an order behind them. Today, by hand.
- Fix the requisition and order discipline. This is process, and it is free.
- Move goods receipt to where goods actually arrive.
- Turn on matching with tolerances you chose, and give the exception queue an owner.
- Then connect the network, into a business that can use what it delivers.
Four questions, and what a vague answer usually means
Does your system do three-way matching?
The answer you often get
Yes, it is standard.
What to press for instead
Everybody says yes. Ask what happens to a failed match — specifically, whether it blocks payment or produces a warning somebody can click past. Ask who is notified, and ask to watch it on a real invoice with a real discrepancy rather than a clean demo record.
Can we set our own tolerances?
The answer you often get
Yes, they are configurable.
What to press for instead
Ask whether price and quantity can differ, and whether a percentage can be combined with an absolute floor. A single global percentage is the answer that sounds configurable and is not, and it is the one that generates a queue nobody reads.
Can goods be received on a phone at the gate?
The answer you often get
Yes, we have a mobile app.
What to press for instead
Ask what it does with no signal. A mobile app that requires connectivity is a desktop screen on a small display, and the yard where your goods arrive is exactly where the coverage is worst. Ask what happens when two people record the same delivery after a sync.
How many of our invoices would fail the match today?
The answer you often get
That depends on your data.
What to press for instead
Correct, and that is the point — so ask them to load one real month and show you. A vendor unwilling to run your own worst month through their software before you sign is telling you something about what the implementation will feel like.
What AWRA OpsHub does today
- Requisitions with approvals that refuse above a threshold
- Purchase orders carrying agreed price and quantity
- Goods receipt at the point of delivery, offline-capable, syncing without duplicates
- Three-way matching with separate price and quantity tolerances
- An exception queue that holds rather than warns
- Landed cost allocated onto the consignment
- Supplier documents attached, with expiry dates watched
What it does not do
- Any e-invoicing network connection — no Peppol access point, no accreditation anywhere
- Parsing of structured invoice formats such as PINT or UBL XML
- Optical capture of scanned or emailed PDF invoices
- Supplier-side portals for vendors to submit invoices themselves
What is not built for Oman today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Oman. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If inbound Fawtara documents landing on your purchase records, an Arabic interface, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The receiving end of Fawtara
A link to your accredited service provider that works in both directions: our sale handed over in the shape their access point expects, and — the part nobody quotes for — an inbound supplier document arriving as data and landing against the purchase order and goods receipt it belongs to, so the three-way match happens before anyone approves payment rather than after. We will not become your access point or hold the accreditation; that belongs with a provider registered on the network, and we would rather say so than sell you the pipe.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds and card acquirer settlements wired into the Payments Register so collections match invoices without anyone re-keying a statement.
Payroll and statutory returns
An Omani payroll engine with Social Protection Fund contributions calculated on live employee records, wage files in the layout the Ministry of Labour and Central Bank system expects, and the Omanisation position visible before a deadline rather than after one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedThat last list is worth reading carefully if you arrived here from an e-invoicing search. We are the layer underneath, not the pipe. The pipe is somebody else's build and there will be competent people selling it in every market where a mandate lands.
Our take
Three-way matching is unglamorous, forty years old, and the single highest-return control most operations do not have. Structured e-invoicing does not replace it — it removes the accidental substitute that was standing in for it and raises the stakes on not having it. If a mandate is coming, use it as the reason to fix the purchase discipline first. The order matters more than the software.
Run your worst month through it
Not our data — one real month of your own purchase invoices, checked against your own orders and receipts. The proportion that match cleanly is the number this whole decision turns on, and you keep it whether or not you buy anything.
Talk to us about procurement controlFrequently asked questions
Is three-way matching worth it for a small business?
It depends far less on your size than on how many suppliers you have and how variable your prices are. A business with eight suppliers on fixed price lists genuinely does not need it — the owner will spot a wrong invoice. A business with sixty suppliers, negotiated prices and goods arriving at three locations has already lost the ability to spot anything, whatever its headcount. Count your suppliers and your delivery points, not your staff.
What tolerance should we set?
There is no universal answer, but there is a shape. Quantity tolerance should be at or near zero, because a quantity difference is a fact rather than a judgement. Price tolerance should be a small percentage combined with an absolute floor so that trivial differences on small orders do not fill the queue. Start tighter than feels comfortable and loosen it after a month of real exceptions, rather than the reverse — a queue that starts noisy gets ignored permanently.
What about invoices with no purchase order at all?
They cannot be matched, by definition, and pretending otherwise is where most matching projects quietly fail. The useful move is to measure the proportion, categorise it, and shrink it deliberately: some of it is genuinely un-orderable — utilities, statutory fees — and should be routed to a different approval path entirely, while the rest is a discipline problem with a named owner. What you must not do is configure the system to let unmatched invoices through silently, because that converts the control into a report nobody reads.
Does electronic invoicing make matching easier or harder?
Easier mechanically, harder in practice. The invoice data arrives clean and structured, which removes transcription error and speeds everything up. But the speed is the problem: the informal check that happened during keying disappears, and the invoice now arrives faster than your own order and receipt records are being created. If your receipt is entered on Friday from a folder of delivery notes, a Tuesday invoice will have nothing to match against for three days, and the pressure will be to pay it anyway.
Can you receive goods without a signal?
Yes — receiving, counting, issuing and dispatch keep working offline and sync once when connectivity returns, without creating duplicate records if two people captured the same delivery. This matters more than it sounds, because the places goods actually arrive are gates, yards and sites, which are reliably the worst-covered locations in any operation.
Do you read PDF invoices automatically?
No. There is no optical capture, no email ingestion and no parsing of structured invoice formats. A purchase invoice is entered or imported, and then matched. We would rather state that plainly than let an "AI-powered" line in a feature list imply a capability that would need to be reliable to be worth anything.
