Document reading
Invoices, receipts and the other documents your team types in by hand hold their information in text and layout. We build the step that reads them into fixed fields, such as supplier, date, lines, VAT and totals, checks every value against your rules, and hands the result on for approval. A document that fails a check goes to a person, with the reason.
This is for you if
- Someone reads every supplier invoice and types the lines into the accounting system.
- Receipts, statements and invoices arrive as PDFs and photos, in every layout.
- When a figure is questioned, someone has to dig out the document it came from.
What you leave with
- The result
- Documents that arrive as checked, structured data. Every document comes back in the same fields, whatever its layout. Each field points to the page and the place it was read from, and the raw file is kept unchanged.
- Read in fixed fields
- The model answers in a fixed format, which your own code checks again before anything is used. Reading every document the same way repeats and is well defined, so it runs on its own.
- Checked by named rules
- The lines add up to the totals, the VAT rates are valid, the supplier is known, the dates make sense. A document that fails a check is flagged with the reason and goes to a person.
- Handed on for approval
- The checked lines go into your accounting system's import, where your bookkeeper approves them, or into your data warehouse. Nothing is posted before a person approves it.
What we do, what you do
| We | You |
|---|---|
| Write the fields for each kind of document from what your receiving system needs. | Pick the documents your team types in by hand, and show us where the data must go. |
| Write the checks as named rules, and test the reading on documents where the right answer is already known. | Tell us your rules: which suppliers you know, which VAT rates apply, what counts as right. |
| Hand the checked lines on to your accounting system's import or your data warehouse, each linked to its document. | Your bookkeeper reviews the flagged documents and approves the rest in the system they already use. |
| Run it as small functions in your own Google Cloud or Azure. Gathena's agents do most of the building, and every change waits for approval. | Someone with admin rights approves changes and controls access. |
Worth knowing
A fixed format does not make the content correct. The total field can hold the wrong total, and the supplier field can hold the customer's name. The AI providers say so themselves, and advise you to check the values in your own code. That is why every value is checked against your rules and points back to its page, and why a document that fails goes to a person instead of being guessed.
Your questions
- Which documents can it read?
- Invoices, receipts, statements, contract pages: documents that arrive as PDFs or photos. Each new kind of document gets its own fields and its own checks; the rest of the setup stays the same.
- What happens when a document is unclear?
- Nothing guesses. A document that fails a check, such as lines that do not add up to the total, is flagged with the reason, and your bookkeeper looks at it. The documents that pass go on.
- Does it post anything to the accounting system?
- No. It reads and checks, and hands the lines on for approval. Your bookkeeper approves them in the accounting system, and nothing is posted before that.
- Where does it run?
- The functions, the raw files and the results run in your own Google Cloud or Azure, and you control access. The model that reads the document runs at the provider you chose; in the invoice reader case, that is Google's Gemini API.
- Where do the documents come from?
- From wherever they arrive today. Where invoices only exist behind a supplier's login, they can be fetched from the portal on a schedule first; the portal guide shows how that could be built.