Short answer. Reading a document with AI is not “running the invoice through a model”: it is a six-stage pipeline. Capture deskews, crops and refuses the unreadable photo right away. Reading turns the image into text, Arabic and French mixed. Field filling constrains the output to a schema: an amount is a number, a date is a date, and a field may stay empty. Each field gets a confidence; below the threshold written with your accountant, it goes to a human with the cropped image. Five checks that need no model then verify correctness: sum of lines, total, plausible date, known supplier, duplicate. What passes is written to the ERP; everything is logged with the image. The schema guarantees form, not value: arithmetic, your database and a set of sixty real documents guarantee the rest. Eight weeks, two without code.
This guide is for the distributor, the clinic, the agency and the accounting firm in Algeria whose team copies papers, and the founder settled in France whose app must accept documents photographed by its customers. It details the function that the guide on AI in the app presents in one paragraph, and extends our page on AI functions; it describes what gets built between the photo and the accounting entry.
What the figures say
A schema guarantees form, not correctness. OpenAI’s documentation on structured outputs says the feature “ensures the model will always generate responses that adhere” to the supplied schema, whereas plain JSON mode only guarantees valid JSON; Anthropic’s says structured outputs “guarantee schema-compliant responses through constrained decoding”, with types and required fields assured. Both list the same exceptions: a model refusal, or a response cut by the token limit, may not match the schema. And neither says the value is right: a total of 266,203 read as 266,208 is a perfectly compliant number. What this imposes: the schema avoids errors of form, and rules around the model catch errors of value.
Reading Arabic and French exists in the open, and it gets tested. Tesseract, the most widely used open character-recognition engine, ships data for about one hundred and twenty languages, including Arabic and French; recent models that read the image directly go further on tables, stamps and irregular layouts. We quote no success rate: those you find are measured on clean documents, not on an Algerian invoice photographed at an angle with a stamp over the number. What this imposes: the reading model is chosen on sixty of your real documents, good and bad, with the right values entered by your accountant.
What does not exist: a reading rate that would hold for you. The share of documents that pass without a human depends on your suppliers, your phones, your stamps; in the example below we set 82 out of 100 as an assumption, and say so. What is decided, in writing, is the threshold: below which confidence a field goes to a human. Higher, the team validates more; lower, errors pass alone. And when documents are sensitive, IDs, medical files, the route is decided as in the private deployment guide: reading happens on your servers.
A photographed invoice becomes fields
The pipeline is not described by its model but by what happens to the photo, from the reception counter to the log line.
Capture happens in the app: guided frame, deskew, crop, sharpness check; an unreadable photo is refused right away, while the paper is still on the counter, not the next day. Reading turns the image into text and structure, lines, columns, zones, with Arabic and French on the same page. Field filling asks the model to fill a schema: supplier, number, date, lines, total before tax, tax, total including tax; a field absent from the document stays empty, and every value must be found in the text read.
Confidence per field is what makes the result usable: the invoice number read 0418 or 0413 under the stamp gets 0.72, below the 0.90 threshold, and is not written; it goes to the validation queue with the image cropped on the field, the proposed value, and one key to validate or correct. The other five fields, above the threshold, continue to the checks. Writing to the ERP or accounting goes through the integration described in the guide on integrating existing software, with an idempotency key so a resend does not write twice. The log keeps the original image, the fields, the scores, the checks and the name of who validated what.
Five checks before writing
Between reading and writing, five checks that need no model, only arithmetic and your database.
The sum of lines equals the total before tax: the check that catches a misread digit in a line and the missing page of a forty-line invoice. Before tax plus tax equals including tax: it catches a misread digit in a total. The date is plausible: not in the future, not older than a written duration; it catches swapped day and month. The supplier exists in your database, found by identifier or name; an unknown supplier is not an error, it is a record for a human to create. It is not a duplicate: same supplier, same number, same amount; the check that avoids paying twice for the invoice that arrived by email then on paper.
Three outcomes: the document whose fields are all above the threshold and which passes the five checks is written by itself; the one with a field below the threshold, or a narrowly failed check, goes to a human, who sees only that field; the one that is a duplicate or unreadable is rejected and attached to its reason. The split in the figure, 82, 15 and 3 out of one hundred, is an assumption: it is measured in the pilot, and it moves with the threshold. What does not move: no document is written without passing the five checks, and no human re-enters a whole invoice.
«A schema guarantees that an amount is a number; arithmetic and your database say whether it is right.»
A worked example
An example on volume assumptions, with rules that are not assumptions: a distributor, three hundred invoices and delivery notes a day.
Three hundred documents a day, photographed at reception or received as PDF: that is our assumption, to be measured. A 0.90 threshold per field, written with the accountant in week one and tuned in the pilot, field by field: the total may require 0.95, the payment method settle for 0.80. Sixty real documents in the evaluation set, per type, good and bad, with the right values: replayed at every change of model, instructions or threshold, and a delivery whose score drops is refused, on the principle described in the delivery guide.
One hundred per cent of documents logged with the image, the fields, the scores, the checks and the validator: that is what lets you answer, six months later, “who entered this amount”. If the assumption of 82 documents out of a hundred written by themselves holds, the team only sees fifty-four documents a day, and on each a single field; that calculation is yours to redo with your volume and your threshold. What reading does not replace: the accountant, who moves from re-entry to checking the gaps.
Six documents, what is extracted and what is checked
The six documents we read most often, and for each what is extracted and what is checked.
The supplier invoice: supplier, number, date, lines, totals, payment method; checked by arithmetic, supplier and duplicate, and matched with the purchase order. The customer purchase order, photographed or received on WhatsApp: customer, products, quantities, units; each product is found in the catalogue with synonyms, the unit verified, credit limit and stock consulted, as in the B2B portal guide. The signed delivery note: quantities delivered, stamp, signature; compared with quantities ordered, the gap flagged; it is the proof the pre-seller of the field app brings back.
The ID document: surname, first name, date of birth, number, expiry, in both scripts; compared with each other, and validated by a human every time, because an identity is not guessed. The transfer notice and the statement: date, amount, payer, reference; matched with an open invoice by a rule, never reconciled by intuition. The prescription and the test result: filed in the patient record, with no medical interpretation, read on site and validated by the practitioner, as in the practice guide. The first three form a chain, order, delivery, invoice, that matches by itself and needs a human only on the gap.
«The human does not re-enter the invoice: they see one field, the proposed value, and validate with one key.»
Six traps in document reading
Six traps we see on the document reading we take over, and what the pipeline does against each.
The blurred or skewed photo: deskew, crop and sharpness check at capture, and a new photo requested right away if nothing is readable. Arabic and French mixed, Latin digits and a stamp on top: a reading model that holds both scripts, tested on your documents, and fields written twice compared with each other. The invented field: the model fills in a date that is not on the document; the field may stay empty, confidence is per field, and every value must be found in the text read.
The table across pages: line-by-line reading, sum recomputed, missing page detected by the gap with the total. The duplicate: key supplier, number and amount; the second is blocked and attached to the first. The sensitive document sent outside: a route per document type, on site for IDs and medical files, Europe for the rest, written in week one. The first two are settled at capture and in the choice of model; the other four in the rules around the model, and a pipeline that only “reads” falls into all six.
Seen elsewhere: structured outputs, Tesseract, and what transposes
Two sources say the essentials. The vendors’ documentation says a structured output respects the schema, except on refusal or a cut response, and says nothing about the correctness of values; what transposes is that we stop writing code to repair JSON and write checks on values instead. Tesseract’s language list says reading Arabic and French has existed in the open for a long time; what transposes is that a simple document is read without sending anything outside, and a more capable model is only justified on tables, stamps and difficult layouts.
What these sources do not say: which documents arrive at your company, in what state, which fields your accounting expects, and what threshold your accountant accepts; the project’s first two weeks answer that, with sixty of your documents on the table.
The rules of document reading that holds
Six rules, written in the first week. One document type at a time, with its fields, checks and threshold. The evaluation set before the code: sixty real documents per type, right values entered by your accountant. A field may be empty; a value with no trace in the text read is refused. No write without the five checks. The human sees a field, not a document: the cropped image, the proposed value, one key. The image is kept, with the scores and the validator, as long as the entry.
A seventh rule concerns the quote: “invoice OCR” is not a requirement, it is a sentence; the requirement reads “reading of photographed supplier invoices, fields X, Y, Z and lines, schema, confidence per field, threshold adjustable per field, five listed checks, per-field validation screen, writing to such software with idempotency, log with image, score measured on sixty real documents at acceptance, data route per document type”, and it is checked as the specification guide recommends. A quote that prices “an OCR” has priced reading, not reliability.
Six companies, and the document read first
Six companies we often equip, and for each the first document chosen in the first week.
- The distributor and the wholesaler. Supplier invoices and signed delivery notes, matched with orders; that is where re-entry is heaviest.
- The accounting firm. Purchase and sales invoices of dozens of clients, each with its suppliers; a shared schema, a supplier base per client, a validation screen per file.
- The clinic and the practice. Prescriptions and results scanned into the patient record, on site, without interpretation, validated by the practitioner.
- The real-estate agency and the owner’s space, described in the dedicated guide. Documents of a rental file and receipts, read and filed, IDs validated by hand.
- The delivery platform and pre-sales. Signed delivery notes photographed in the field, read offline or at the synchronisation described in the offline guide.
- The founder in France. Documents and proofs uploaded by the customers of their app; reading, checking, and a dashboard of incomplete files as in the dashboard guide.
The 2027 calendar
The calendar is that of complete document reading in eight weeks, two without code.
Week 0 to 1 writes the documents, fields and thresholds: the two or three types chosen, the fields per type, the checks, the threshold per field, the data route; signed. Week 1 to 2 builds the evaluation set: sixty real documents per type, clean and damaged, with the right values entered by your accountant. Weeks 2 to 4 build capture, reading, schema, confidence, the five checks and the log; the score on the set is measured from the first delivery. Week 4 to 5 builds the validation screen, the one that decides adoption: if it takes more than a few seconds per field, the team goes back to re-entry.
Week 5 to 6 wires writing to the ERP or accounting, with order, delivery, invoice matching and idempotency. Weeks 6 to 8 are the pilot on the day’s documents: share written by itself, share validated, share rejected read every day, threshold tuned field by field, cases added to the evaluation set. Every two-week batch is demoed and accepted on the set.
What makes document reading fail
The document reading we take over almost always failed for one of these reasons.
- OCR with no check. The text is read, written as is, and errors are found at reconciliation.
- No confidence per field. Everything passes, or everything goes to a human; nothing in between.
- The human re-enters the whole document. The validation screen shows the invoice, not the doubtful field; the gain disappears.
- Acceptance on clean PDFs. The pilot’s documents are skewed photos with a stamp.
- No duplicate check. The same invoice, received twice, is paid twice.
- The image is not kept. Six months later, nobody can say where the amount came from.
- IDs sent to a vendor with no contract. The data route was never written.
Frequently asked questions
The questions we receive from managers, accountants and founders.
- Can AI read our invoices in Arabic and French?
- Yes, provided it is measured on your documents: reading Arabic and French exists in the open, and recent models read the image directly, tables and stamps included. We choose the model on sixty of your real documents, good and damaged, with the right values entered by your accountant, and we quote no rate before measuring it.
- What happens when the reading is wrong?
- Two nets. Confidence per field: below the threshold written with you, the field is not written and goes to a human with the cropped image. The five checks: sum of lines, total, plausible date, known supplier, duplicate; a value that matches the schema but is wrong is caught by arithmetic or by your database. Nothing is written to accounting without both.
- Does a human still have to step in?
- Yes, on what deserves it: fields below the threshold, unknown suppliers, gaps between order, delivery and invoice, and always IDs. They do not re-enter the document: they see one field, the proposed value, and validate or correct with one key. The share of documents concerned is measured in the pilot and tuned by the threshold.
- Where do our documents go?
- Where the document type is allowed to go, written in week one: IDs and medical files are read on your servers; invoices may be read by a vendor hosted in Europe with a contract in your name, or on site if you ask. The original image stays in your database, with the log.
- Does it integrate with our accounting software?
- Yes, through the API when it has one, by import file or another route when it has none, with an idempotency key so a resend does not write twice. Order, delivery, invoice matching happens before writing, and the validation screen is not in your software: it is a light queue, on computer or phone.
- How long to set it up?
- Eight weeks for two or three document types: one for fields, checks and thresholds, one for the evaluation set, two for reading and checks, one for the validation screen, one for writing to the ERP, two of pilot with threshold tuning. Every two-week batch is demoed and accepted on the set.