Three Fields and the Whole Page
The invoice reader returns the whole page as text and three candidate values: a total, a date and a document number. It returns no line items, and everything it does return is a suggestion. Knowing exactly that is what makes it useful.
Every claim about reading invoices automatically is really a claim about how often it is wrong, and almost none of them say.
The invoice reader here does one thing: it turns an image or a scan into text, and then looks for three specific things in that text. It hands back the whole page alongside whatever it found. What it does not do is decide anything.
What comes back
| Field | How it is found | What it is |
|---|---|---|
| The page text | Everything the reader could make out | The most useful part, and the part most people ignore |
| A total | A figure with two decimal places following the words total, amount or grand total | A candidate. Often right, sometimes the subtotal, sometimes a line |
| A date | The first thing on the page shaped like a date | A candidate. Might be the invoice date, the due date or the order date |
| A document number | What follows the word invoice | A candidate, and the one most likely to be exactly right |
| Line items | Not attempted | Empty, always |
The empty list is the honest part
Line item extraction is where invoice reading gets genuinely hard — columns that are not columns, descriptions that wrap, quantities in a different unit than the order, a discount line that looks like an item. A reader that returned a confident, half-right list of lines would be worse than one that returns none, because a half-right list gets accepted and a missing one gets typed.
The three patterns, and what defeats each of them
Being specific about this is more useful than any accuracy figure, because it tells you in advance which of your suppliers' invoices will read cleanly.
-
The total needs a label and a decimal point
It looks for a figure following the words total, amount or grand total, with exactly two decimal places after a point. A total written without decimals, with a comma as the decimal separator, or followed by a currency mark rather than preceded by one, will not be found. Nothing is returned rather than something wrong.
-
The date is the first one on the page
Two shapes are recognised — year first, or day first with a four-digit year. Whichever appears first in the text is returned, and on most invoices several dates appear. It is also not disambiguated: a date written as 03/04/2026 is returned as written, and nothing decides whether that is March or April.
-
The number is what follows the word invoice
Letters, digits and hyphens after the word invoice or inv, with optional punctuation between. This is the pattern that works most reliably, because that word is nearly always on the page and nearly always immediately before the number.
It reads. It does not conclude. Those are different products.
When it fails, it returns nothing
A missing file, an unreadable image, a failure in the reading engine — all of them produce an empty result and a log entry, and none of them produce an error that reaches whoever is uploading. That is a deliberate posture and it has one consequence worth planning for: from the outside, a failed read and a blank page look identical.
It also means the reader can never break the process it sits in. An invoice that cannot be read is an invoice that gets keyed in by hand, which is what would have happened anyway. The alternative — an exception surfacing to a user trying to attach a document — trades a small convenience for a blocked task.
How to use a reader like this well
You process a steady flow from the same suppliers
Check the first ten, then trust the pattern
Invoice layouts are stable per supplier. If the total and the number read correctly on ten invoices from one supplier, they will keep doing so until that supplier changes their template.
You are entering an invoice that matters
Treat every field as a suggestion
The document number is usually right, the date is often the wrong one of several, and the total is right when the layout suits it. Reading the page text beside the form is faster than checking the paper.
A supplier's invoices never read
Look at the number format before blaming the scan
A total written without a decimal point, or with a comma as the decimal separator, will never be found however clean the image is. That is a pattern question rather than a scanning one.
You want the line items
That is the piece to commission
Line extraction is a real project rather than another pattern, and it is where the remaining typing actually is. It is also where a per-supplier template earns its keep.
Where it sits relative to the checks
Worth being clear, because reading an invoice and trusting an invoice are separate steps and it is easy to hear the first as the second. Anything the reader produces still passes through the same matching as a hand-keyed invoice: quantities compared against what was received, prices compared against what was ordered, payment refused where they disagree.
That ordering is the reason a modest reader is safe to use. It saves typing at the front of a process whose controls sit further along, and it has no authority of its own — an amount it extracted is exactly as trusted as an amount somebody typed, which is to say not at all until the documents agree.
Our take
This is a small tool honestly described, and the honest description is the point. Three regular expressions and a reading engine will not impress anybody, and they will save real time on the fields that matter most for filing and retrieval — the document number above all. What would be dishonest is calling it invoice automation, because it decides nothing and extracts no lines, and the typing that hurts is the lines. Two things make it safe to keep in the process while it is this modest: it fails to nothing rather than to something wrong, and everything it produces still faces the same matching as a hand-keyed invoice. If you want the rest, line extraction with a template per supplier is the project, and it is a real one.
What AWRA OpsHub does today
- Text extraction from an uploaded invoice image or scan, returning the whole page alongside anything recognised.
- A candidate total, found by looking for a figure with two decimal places following the words total, amount or grand total.
- A candidate date, matching a year-first or day-first format and returning the first one found on the page.
- A candidate document number, taken from what follows the word invoice, which is the most reliable of the three.
- A failure that returns an empty result and writes a log entry, so an unreadable document never blocks the person uploading it.
- Extraction that has no authority of its own — everything it produces faces the same three-way matching as a hand-keyed invoice.
- The raw page text returned in full, which is often more useful than the three fields for checking a document without opening the file.
More we can add to your workspace
- Line item extraction, reading quantities, descriptions and unit prices into rows that can be matched against an order.
- A template per supplier, so a layout that reads badly once can be taught rather than worked around every month.
- Date disambiguation, deciding between a day-first and a month-first reading and labelling which date on the page was chosen.
- Number formats beyond a decimal point with two places, covering totals written with a comma separator, with no decimals, or with a currency mark after the figure.
- A confidence figure per extracted field, so a form can highlight what to check rather than presenting three values with equal weight.
- A reconciliation of the extracted total against the order, offered at the point of entry rather than at the matching stage.
- Supplier identification from the page, matching a letterhead to a record in your supplier list.
Where we point you to a specialist
- We will not return a confident line-item list from a layout the reader has not been taught. A half-right set of lines is accepted by a tired person at the end of a month and then matched against an order it does not describe — which is a worse outcome than an empty list somebody has to fill in.
- We will not treat an extracted figure as more trustworthy than a typed one. Everything from this reader faces the same matching against what was ordered and what was received, and any design that let a machine-read total skip a check would put the weakest input on the fastest path.
- Where an invoice is a legal document with a prescribed format — a fiscal receipt, a tax invoice carrying a control code — the authoritative source is that document and any structured feed the authority provides, not our reading of a picture of it. We will point you at the feed rather than parsing the page.
A template per supplier is the piece that changes the economics here, because invoice layouts are stable per supplier and a taught layout reads its lines reliably where a general parser cannot.
From three fields to the lines
The reading engine and the plumbing exist. What turns this from a filing convenience into a saving is the line items, and the reliable route to those is per-supplier layouts rather than a cleverer general parser.
Line item extraction
Quantities, descriptions and unit prices read into rows, so an invoice can be matched against an order without retyping it.
A template per supplier
Teach a layout once and every subsequent invoice from that supplier reads the same way, which is where the reliability actually comes from.
Confidence per field
A form that highlights the two values worth checking rather than presenting three with equal weight.
We publish scope, not dates.
Scope invoice captureFive questions to ask any invoice reader
Which fields does it extract?
A good answer sounds like
A named list, not "invoice data".
What ours actually is
The page text, plus a candidate total, date and document number. Line items are returned as an empty list.
What happens when it cannot read something?
A good answer sounds like
Nothing rather than a guess.
What ours actually is
The field is returned empty. A total that does not match the pattern produces no total rather than a wrong one.
Does an extracted figure skip any checks?
A good answer sounds like
No.
What ours actually is
No. It faces the same matching against what was ordered and received as a figure somebody typed.
What is the accuracy?
A good answer sounds like
A measured figure, or an admission.
What ours actually is
Unmeasured, and we would rather say so than quote one. What we can tell you is exactly which patterns are looked for, which is more actionable.
What happens on a failure?
A good answer sounds like
A safe outcome.
What ours actually is
An empty result and a log entry. The upload succeeds and the person keys the invoice in, which is what they would have done anyway.
Look at one supplier's invoice before deciding
Whether this saves you time is decided by how your suppliers write their totals, and that is a two-minute check on an invoice you already have. It is also the fastest way to scope what a per-supplier template would need to do.
Talk through invoice captureFrequently asked questions
Why does it not return line items?
Because line extraction from an arbitrary layout is a genuinely hard problem — wrapped descriptions, columns that are not columns, discount lines that look like items, quantities in a different unit than the order. A reader that returned a confident half-right list would have those lines accepted and matched against an order they do not describe. An empty list gets typed in, which is slower and correct.
Why did it find no total on my invoice?
Most likely the number format. The pattern requires a figure with a decimal point and exactly two places following the words total, amount or grand total. A total written without decimals, with a comma as the decimal separator, or with the currency mark after the figure will not match — and no total is returned rather than a wrong one.
Which date does it return?
The first one on the page in a recognised shape, which may be the invoice date, the due date or the order date depending on the layout. It also does not disambiguate a day-first from a month-first reading — a date written 03/04/2026 comes back as written. Treat it as a suggestion to confirm rather than a value to accept.
Can an extracted amount be paid without further checking?
No, and not because of a rule about extraction — because every invoice faces the same matching against what was ordered and what was received, whoever or whatever produced the figures. A machine-read total has exactly the same standing as a typed one, which is the property that makes it safe to use a modest reader at the front of the process.
What happens if the file cannot be read at all?
An empty result is returned and a log entry is written. Nothing surfaces to the person uploading, and the document attaches normally. The trade-off worth knowing is that from the outside a failed read looks the same as a genuinely blank page, so a supplier whose invoices never populate anything is worth investigating rather than assuming.
Would a per-supplier template really work better?
Yes, and by a large margin, because invoice layouts are stable per supplier in a way they are not across suppliers. A general parser has to handle every layout ever printed; a taught layout has to handle one, and it can be told exactly where the lines are. That is why it is the first item on the list of what a fuller version adds.
