Supplier invoice OCR in Morocco: what decides the outcome

Every OCR demonstration looks alike. A clean invoice goes in, it is read in three seconds, the fields populate, the room is convinced.

Then the month’s batch arrives: crooked scans, third-generation photocopies, a bilingual invoice, another with the amount corrected in pen. That is where the difference shows between software that holds up and software that gets abandoned within a quarter.

Recognition rate says very little

A vendor quoting 95% recognition tells you nothing usable, for a simple reason: the rate is measured on a sample you did not choose.

The only question that matters is elsewhere: what happens to the other 5%?

• If the badly read invoice is posted anyway, with a wrong amount, your OCR is a discrepancy generator. You will find out at reconciliation, weeks later, and you will look for the error in the wrong place.
• If it is set aside for manual handling, you have a sound tool. It processes what it can process and hands back the rest.

An OCR that hesitates and stops beats an OCR that is sure of itself.

The five checks that separate a tool from a demo

Before anything is posted to the ledger, a read invoice should clear five checks. None is exotic, and missing a single one is enough to undo the whole exercise.

1. Does the supplier exist in the master file? Matching must run on stable data — the ICE number for preference, not the trading name, which varies from one invoice to the next.

2. Does the total match the sum of the lines? A trivial check, and it catches most amount-reading errors.

3. Is the VAT consistent? Base × rate = amount, on each line and on the invoice footer. VAT that does not reconcile signals either a misread or an invoice worth looking at.

4. Is it a duplicate? Same supplier, same document number, same amount. An invoice paid twice is cash out of the door and a cold supplier dispute.

5. Is the due date usable? A misread due date distorts your cash forecast without ever raising an alert.

An invoice failing any of these should not be posted. It should be flagged.

What makes reading harder in Morocco

The Moroccan corpus has its own characteristics, and an engine trained elsewhere discovers them at your expense:

• Bilingual invoices, French and Arabic, sometimes with amounts in Eastern Arabic numerals.
• The regulatory footer: ICE, IF, RC, business tax and social security numbers. Useful — it holds the reliable supplier identifier — but dense, small, and the first thing to degrade in a scan.
• Handwritten notes: a delivery note reconciled by hand, a corrected amount, a stamp pressed across the table.
• Media quality. A meaningful share of supplier invoices still arrives on paper, and scanning happens with whatever the office has.

None of this is disqualifying. But it explains why a rate measured on European invoices does not transfer.

Where OCR must stop

An architectural principle, and it is not negotiable: never read straight from the Sage database for posting, and never write to it directly.

Direct reads are legitimate for reporting. Direct writes never are: the Sage data model carries rules — counters, header-to-line consistency, analytical postings — that are not all encoded in the SQL schema. A write that ignores them produces a database that is consistent for SQL Server and inconsistent for Sage. The symptom shows up at period close.

An OCR-recognised invoice must enter Sage through the same path as a hand-keyed one, with the same controls. It is an order of magnitude slower. It is the only way to get accounts you can rely on.

Paying for reading or paying for posting

An OCR’s billing model is not a commercial detail. It is a usage detail.

If the meter runs on reading, every attempt costs you. Teams hesitate to submit a doubtful invoice, calibrate less, and end up working around the tool for the hard cases — precisely the ones that justified the investment.

If the meter runs on posting, the incentive inverts: an unreadable scan costs nothing, a calibration attempt costs nothing, an invoice rejected by the checks costs nothing. You only pay for what actually reached the ledger.

That is the model in OptiFlow OCR, and it was not chosen for commercial reasons. It was chosen because the other model discourages exactly the behaviour you want.

A practical corollary: the counter must be permanently visible to the team. Nobody should discover an exhausted quota on closing day.

A five-point pilot protocol

If you are evaluating a solution, ignore the demonstration. Do this instead:

1. Assemble a hundred real invoices, taken at random from one month, without discarding the bad scans.
2. Count the invoices posted without intervention. That is your real rate.
3. Count above all the invoices posted with an error. That number must be zero. If it is not, the tool is disqualified whatever its recognition rate.
4. Time the manual handling of rejected invoices. A tool that rejects a lot but makes recovery fast is still a good tool.
5. Check what was billed during the pilot, and on what basis.

The return calculation then works itself out, on your volumes and your costs, without a salesperson doing it for you.

Going further

The OptiFlow OCR module page details the checks applied before posting and how the counter works.

If you would rather test this on your own invoices than on ours, that is what the demo is for.