Key takeaways
- OCR converts an image of an invoice into text; it does not know which number is the total, which is the VAT and which is the net.
- Invoice automation adds structure, VAT arithmetic, coding to the chart of accounts, duplicate checks and posting, with a review step for anything uncertain.
- The expensive quarter-end errors, an inclusive total read as net or one rate applied to a mixed receipt, happen after OCR, not during it.
- Ask of any tool where its OCR stops and what happens to the output next: if the answer is a person keying it, the automation stopped at the first step.
01What OCR actually does
Optical character recognition turns a picture of text into text. Point it at a scanned invoice and it returns the characters: the supplier's name, a column of descriptions, some numbers, a VAT number, a total. What it does not return is meaning. It does not know which of the numbers is the total, whether 19.00 is a rate or an amount, or whether the figure at the bottom includes VAT.
Modern OCR is good at reading, which is why "our OCR is very accurate" is rarely the point. A perfect transcription of an invoice is still a transcription, and somebody has to turn it into an entry in the books. If that somebody is a person with a keyboard, the practice has bought a faster way to look at the document, not a faster way to post it.
In Pileform the OCR pass has one job: to transcribe exactly what is printed. It is not allowed to correct a number, even one that looks wrong, because a transcription that quietly fixes figures cannot be audited. Everything that turns the transcription into bookkeeping happens in later stages, where it can be checked.
02What invoice automation adds on top
Invoice automation is the chain that starts where OCR stops. For each document, in Pileform:
- Structure. The text becomes fields: supplier, VAT number, invoice number, dates, currency, and line items with quantity, unit price and rate, then subtotal, VAT and total.
- Arithmetic. Deterministic code parses every amount to integer cents and checks that the lines add up to the subtotal and the total. When they do not, the original image is read again; if the money still does not reconcile, the row is flagged for a person.
- VAT. The rate is read per line, the pricing mode (inclusive, exclusive, reverse charge) is detected from the document's own wording, and the rate is checked for plausibility, with anything odd flagged rather than corrected.
- Coding. Each line is mapped to the company's own chart of accounts: rules and remembered suppliers first, then an AI suggestion above a confidence floor, then a person.
- Duplicates. The same invoice uploaded twice, or already posted, is caught before it enters the books a second time.
- Posting. Once a person confirms it, the entry posts to the ledger as a bill or a journal, and the Excel workbook keeps the source image beside the figures.
None of those steps is reading. They are interpretation and control, and they are where the time at quarter end actually goes.
03Where the quarter-end errors actually happen
The mistakes that force a Cyprus VAT return to be corrected are almost never OCR mistakes. They happen at the interpretation step:
- An inclusive total read as a net. A Greek receipt printing «ΦΠΑ συμπεριλαμβάνεται», a French one printing «TTC»: read the total as net and VAT is charged on VAT.
- One rate for a mixed document. A hotel folio or a supermarket receipt carrying more than one of the Cyprus bands (19 / 9 / 5 / 3 / 0) coded at a single rate.
- Reverse charge missed. An EU supplier's invoice under Article 196 posted as if it carried Cyprus input VAT, when the VAT belongs in both the output and the input boxes of the return.
- The same invoice twice. Once in the first batch the client sent, once again in the resend.
OCR could transcribe every one of those documents perfectly and every one of those errors would still happen. They are caught by arithmetic, by reading the wording in the document's own language, and by checks against what has already been posted. The per-line VAT post works through the mixed-rate case in detail, and the reverse charge guide covers the return side.
04How to tell which one you are buying
Product pages use the two terms loosely, so test the output rather than the label. Upload one real quarter of one client and look at what comes back.
- Text, or entries? If the output is a table of what was printed, it is OCR with a spreadsheet around it. If it is proposed entries with net, VAT, rate and account per line, it is automation.
- Does it reconcile? Every document's lines should add up to its printed total, with cash rounding shown in its own column rather than absorbed into a line.
- Does it show doubt? Look for rows marked as inferred or as not reconciling. A tool that shows none has either read a perfect pile or is not telling you.
- Does it post? Confirmed entries should reach your ledger, and the workbook should keep the source image so an inspector can match the figure to the paper.
Pileform turns a typical 200-page quarter-end PDF into per-supplier workbooks and proposed entries in about 12 minutes, and posts only what a person confirms. If all you need is the text of a document, an invoice OCR tool will do. If you need the quarter in the books, the question is how much of the chain after OCR a tool covers.
OCR answers what the page says. Invoice automation answers what it means for the books, and at quarter end the return depends on the second answer.
Pileform is invoice automation for Cyprus and Europe: extraction, per-line VAT, coding, duplicate checks and posting to Xero, QuickBooks, Business Central, BTMS or Esoft, with an Excel workbook you keep.