We shipped a broken demo and did not notice for nineteen days
On 7 August we put an invoice-extraction prototype on this site. You paste in invoice text, it pulls out the supplier, the invoice number, the date and the amount payable. It looked like it worked. It returned a supplier name, a date and a number with a currency symbol in front of it, laid out in a tidy result card. Nobody complained.
On 26 August we tested it properly for the first time, and it was wrong on 37 of 40 invoices.
The worst defect was a single word. The code looked for the word total to find the amount payable. The word total also appears inside the word Subtotal. So on every invoice that listed a subtotal and then added tax, the extractor grabbed the subtotal — the pre-tax figure — and presented it as the amount due. It understated the payable amount by exactly the tax, every single time, and it did so with total confidence and a clean-looking result.
Twenty-six of our forty test invoices carried a subtotal line. All twenty-six were wrong.
The failure mode that matters is not the crash
If that demo had thrown an error, someone would have reported it in a day. Errors are loud. They interrupt people. They get fixed.
Instead it returned a plausible number. A plausible number is worse than no number, because a plausible number gets used. Had that extractor been wired into a real accounts payable process, it would have quietly underpaid suppliers by the tax amount on every invoice with a subtotal line, and the error would have surfaced weeks later as a reconciliation problem nobody could trace.
This is the thing to hold onto when you evaluate any AI automation demo, ours included: a demo proves that the system produces output. It does not prove the output is correct. Those are entirely different claims, and almost every demo you will be shown only establishes the first one.
What the numbers actually looked like
We built a corpus of 40 invoices and scored four fields on each — supplier, invoice number, invoice date, payable total. That is 160 individual checks. Before the fix:
- Supplier: 40 of 40 correct. This field was genuinely fine, and it was the field that made the demo look healthy.
- Invoice number: 7 of 40. The pattern only recognised references beginning with the letters
INV. Anything formatted asInvoice No: 2291,Tax Invoice No: KST/2026/0417orBill # PT-99123came back as "Not detected". - Invoice date: 16 of 40. The date pattern was allowed to run across line breaks, so on some invoices it stitched together a day number from one line and a year from several lines below.
- Payable total: 14 of 40. The subtotal problem, plus a second one: a colon after the label defeated the match entirely, so
Grand Total: PKR 573,480fell through to a generic money-finder that returned the first number anywhere on the page.
Overall: 77 of 160 fields correct, 48.1%. Three invoices out of forty came through completely right. After the fix, 160 of 160 and 40 of 40.
Be suspicious of our 100%, too
That "after" figure deserves the same scepticism we are asking you to apply to everyone else.
We wrote the invoices. We chose which formats to include. A perfect score against a corpus we designed proves the parser handles the cases we thought of, which is a much smaller claim than it sounds. The formats we did not think of remain untested, and there will be some.
What the corpus does not contain: OCR noise, scanned or photographed documents, multi-page invoices, line-item tables, credit notes, multi-currency totals, or handwriting. The demo accepts pasted text rather than PDFs, so nothing in that test measures document ingestion at all.
There is one more thing worth admitting. Our first scoring run reported 34 of 40 after the fix. Six of those apparent failures were not failures — the scorer was treating Rs. 87,051 as a different value from 87,051 because of a stray full stop. We fixed the scorer and re-ran before recording anything. We mention it because a measurement harness is software too, and it can be as wrong as the thing it measures.
Five things to make a demo prove
Apply these to any vendor. Apply them to us.
1. Make it accept your input, not theirs
Paste in one of your own documents, messages or requests — ideally an awkward one. A demo that only performs on the sample data shipped with it is a rehearsal, not a test. If the interface will not accept arbitrary input, you are watching a video with extra steps.
2. Check the answer against ground truth you already know
Do not evaluate whether the output looks right. Pick an input where you already know the correct answer and compare digit for digit. Our extractor produced beautifully formatted wrong numbers for nineteen days precisely because nobody did this.
3. Feed it the edge case on purpose
Every process has a shape that breaks the naive version: the invoice with a subtotal, the customer who asks two questions in one message, the CV with dates in the wrong order. You know what yours are. Try one deliberately. A vendor who welcomes this is telling you something; a vendor who steers you back to the happy path is telling you something too.
4. Ask what happens when it is unsure
The correct behaviour for an uncertain system is to say so and stop. The dangerous behaviour is to produce a confident answer anyway. Ask directly: what is the confidence threshold, what happens below it, and who gets told? "It always returns something" is not reassurance.
5. Ask for the failure rate, and how it was measured
Any accuracy figure needs three things attached before it means anything: what was tested, how many, and who wrote the test data. A number without those is decoration. If a vendor cannot tell you how they measured it, they have not measured it.
What we changed
The total matcher now looks for the specific labels that actually denote a payable amount — grand total, amount due, total due, balance due, total payable, invoice total, net payable — before falling back to a plain total anchored at the start of a line, and it will not match inside Subtotal under any circumstances. Invoice-number detection now handles labelled references rather than assuming a fixed prefix. Date patterns no longer cross line boundaries, and ISO dates are tried first.
The fix is live. You can test it yourself, with your own invoice, on the prototype linked below.
The uncomfortable point
We found this because we went looking, and we went looking because we needed evidence for something else. That is not a system. It is luck.
The honest conclusion is not "SmartBiz demos are reliable." It is that automation which processes documents or messages without a human reading every result needs a measurement harness from day one, and a way to notice when accuracy drifts. A demo shows you the ceiling on a good day. What determines whether automation is worth buying is the floor on a bad one — and nobody demonstrates the floor voluntarily.
Ask them to.