Invoice extraction is one of the few genuinely solved AI problems in a contractor's back office. The work is not getting it to read — it is deciding which fields it must never get wrong, and what happens when it is unsure.
Key takeaways
A busy contractor receives supplier documents in every possible shape: a PDF from the lumber yard's system, a photograph of a crumpled delivery ticket, a scanned statement covering six invoices, an emailed body with no attachment at all. Somebody keys them. That keying is expensive, late and error-prone, and it is the single clearest candidate for automation in a construction back office.
Modern document models do not "read the text and hope". They return a structured object. Microsoft's prebuilt invoice model documentation describes output in three parts: a section containing all recognised text and selection marks organised by page, line and word; a section containing tables and cells with their bounding boxes and confidence and references back to the underlying lines and words; and a section containing the invoice-specific values and line items the model discovered — invoice ID, ship to, bill to, customer, total and line items among them. It also notes that the return of key-value pairs is optional and disabled by default, and that the model is trained to extract identifiable keys and their associated values.
Two features of that design matter operationally. Bounding boxes mean every extracted value can be traced back to a location on the page, so a reviewer sees where a number came from instead of taking it on faith. Confidence values mean you can set a threshold and route anything below it to a person. Google documents the same general pattern across its range of Document AI processors, and the broader Document Intelligence overview describes the same extraction of text, key-value pairs and tables from documents generally.
Here is where a generic setup quietly fails a Canadian business. A default invoice extractor is tuned for the fields most systems want: number, date, total. Canadian rules require more, and they require it as a condition of claiming the tax back.
Paragraph 169(4)(a) of the Excise Tax Act makes an input tax credit conditional on obtaining prescribed information, and section 3 of the Input Tax Credit Information (GST/HST) Regulations prescribes it in three bands. Below $100: the supplier's or intermediary's name or business name, the date, and the total amount paid or payable. From $100 to under $500: those, plus the registration number assigned to the supplier or intermediary under section 241 of the Act, plus the tax amount, plus an indication of status where supplies of different status appear together. At $500 or more: those, plus the recipient's name or business name (or a duly authorised agent's or representative's), the terms of payment, and a description of each supply sufficient to identify it.
The regulation also defines supporting documentation broadly — an invoice, a receipt, a credit-card receipt, a debit note, a book or ledger of account, a written contract, and any record contained in a computerised or electronic retrieval or data storage system. That last item is the reason a well-built digital capture pipeline is acceptable at all, and the reason its output has to be complete.
The extraction schema worth configuring
Always: supplier name, document date, invoice number, total amount, source file reference.
From $100: supplier GST/HST registration number, tax amount by rate, taxable status where mixed.
From $500: recipient name as printed, terms of payment, line-level descriptions.
For job costing: purchase order or job reference, delivery site, line quantities and unit prices.
For control: a confidence value per field, and the page coordinates behind each one.
The difference between a capture project that sticks and one that gets abandoned is almost always the review queue. Set a confidence threshold per field rather than per document — a total at 0.99 and a registration number at 0.61 is one document that needs a human glance at one field, not a full re-key.
Three rules that hold up in practice. First, never auto-post a document where a legally required field is missing entirely; missing is different from uncertain and deserves a harder stop. Second, treat any new supplier's first three documents as review-always, because that is where format surprises live. Third, watch duplicates: the same invoice arriving as an email attachment and again on a monthly statement is the most common cause of double-posting, and a match on supplier plus invoice number plus amount catches nearly all of it.
Printed invoices are the easy case. Contractors also deal with handwritten site tickets, carbon-copy delivery slips and photographs taken in bad light on a phone. Handwriting recognition has improved substantially, but a handwritten quantity on a smudged ticket is exactly the kind of value that should never post unreviewed — the failure is not that the model refuses, it is that it produces a plausible number.
Two practical mitigations. Capture at the point of delivery rather than at the end of the week, while the person who received the load can still confirm what arrived. And where the ticket has no total — common on delivery slips — do not let the pipeline invent one; route the ticket to the purchase order it belongs to and reconcile it against the invoice when that arrives.
Extraction produces data; it does not replace the document. Paragraph 230(4)(b) of the Income Tax Act requires records and books of account, together with every account and voucher necessary to verify the information in them, to be retained until six years from the end of the last taxation year to which they relate, and subsection 230(4.1) requires records kept electronically to be retained in an electronically readable format for that period. Section 286 of the Excise Tax Act mirrors this for GST/HST: records kept in Canada in English or in French unless otherwise authorised (subsection 286(1.2)), six years (subsection 286(3)), and electronically readable where kept electronically (subsection 286(3.1)).
In practice: store the source image alongside the extracted fields, in a common format you can open without the capture vendor's software, and check that your export includes attachments and not just rows. Our sister firm's note on record-keeping that survives a CRA audit covers the same ground from the legal side.
Setting up capture at a mid-size GC, illustrative
Week one. One inbox for every supplier document. No sorting, no folders, no rules — a single destination is worth more than a taxonomy nobody maintains.
Week two. Extraction configured to the schema above, with thresholds set deliberately high so that almost everything is reviewed. The point of week two is to learn where the model struggles on your suppliers, not to save time yet.
Week three. Thresholds relaxed field by field on the strength of what week two showed. Repeat suppliers with clean PDFs auto-post; photographs and handwriting stay in the queue.
Week four. Duplicate detection on supplier, invoice number and amount. Two double-postings from the previous quarter surface during setup and get reversed.
Steady state. A queue that takes twenty minutes a day instead of two days a week, and a payables ledger current enough that job cost reports are worth reading.
Many accounting platforms include capture. The question to test is not whether it captures, but whether it captures the registration number and tax split reliably on your suppliers' documents. Run five real invoices across the three regulation bands before deciding.
Coding is a separate model learning from your history, and it works well on repeat suppliers. Keep the two decisions distinct in your review queue — a correctly read invoice coded to the wrong job is a reporting error that is much harder to spot later than a misread number.
There is no universal number, and any vendor quoting one for your documents is guessing. Derive it from your own week two: sort a few hundred processed documents by confidence, find where errors start appearing, and set the threshold above that point.
Ask where the data is processed and stored, whether it is retained, and whether it is used for training — and get it in the agreement. Note also the Excise Tax Act requirement that records be kept in Canada in English or in French unless the Minister authorises otherwise, which is a question about where your system of record sits, not merely where processing happens.
A 30-minute call is enough to tell you whether AI pays for itself here.
