Documentation/ Checking the document header/ How a document is read
How Dijit reads a document
Knowing what the system does with a document explains why some fields always come out right and others want a look. There are four stages and it takes under three seconds a page.
On this page
The four stages
| Stage | What happens |
|---|---|
| 1. Recognition | OCR turns the image of the document into text you can find things in. |
| 2. Extraction | The AI models work out what each value is: which of those bits of text is the issuer, which the date, which the net amount. |
| 3. Checking | The document is tested against itself: that net plus taxes is the total, that the lines add up to the net, that the tax breakdown agrees, and that this is not a document you already have. |
| 4. Coding | Nominal accounts are filled in from your company's history and the rules you have set. |
What comes out of stage three is what decides the status the document shows in the list.
OCR and artificial intelligence
They are two different things and you need both:
- OCR recognises characters: it turns pixels into text. OCR on its own would give you a tangle of words and numbers with no idea what any of it was.
- Generative AI interprets: it works out that the nine-digit number next to a company name is a tax reference, and that the figure at the bottom is the total and not a page number.
Which is why the system does not depend on a template per supplier: it does not need to know in advance where each one prints what.
Accuracy, and what it turns on
Average accuracy on reading and coding is 99 % on an original PDF. On photographed documents it follows the quality of the image.
| Where the document came from | How it behaves |
|---|---|
| A PDF made by the sender's system | The text is inside the file. The best case there is. |
| A scanned PDF | Needs recognising. Good, with a clean scan. |
| A photograph | Sensitive to framing, lighting and shadows. |
| A thermal receipt or a worn photocopy | The worst case: the original has already lost information. |
The practical upshot: when a document is always read badly, look at how it arrives before you correct it again and again. Improving the source settles more than correcting the result.
What it learns from your history
The system does not treat every document as if it were the first:
- Nominal accounts are filled in from what was done before with that issuer.
- Correction rules you create are applied to that supplier's later documents.
- Unit conversions and agreed prices stay attached to the item and the supplier.
Which is why there is more checking in the first month than in the sixth: every correction takes work off the future.
What it will not do
It does not fill in data that is not on the document. If a value is not there, or cannot be read, the field is left empty and the document is flagged for a look. An empty field is not a reading failure: it is the record that there was nothing legible there.
Nor does it decide for you: it checks and it flags, but approving is always down to a person or to the route you have set up.
Where it all happens
The models run inside Dijit.app's own Azure estate, on servers in the European Union. Customer documents are never used to train models.