How accurate are AI assistants with business numbers and records?

“How accurate is it?” sounds like one question, but a business assistant crosses several accuracy boundaries before a number becomes a record. It must retrieve the right email or document, identify the relevant value, assign it to the correct field, normalise its format, calculate any total, avoid duplicates, write the intended record and preserve the source. A system can succeed at seven stages and still create the wrong liability because it selected a subtotal instead of the amount due. This guide replaces a vague accuracy percentage with a testable chain. It explains which work benefits from language-model interpretation, which belongs in deterministic code, how provenance and uncertainty affect trust and what Digital Hank's current repository does and does not yet prove.

What does accuracy mean for a business assistant?

Accuracy is the rate of correct end-to-end records under defined conditions, supported by stage-level measures that reveal where errors occur. A single vendor percentage cannot describe every source, field and workflow.

For invoice intake, measure:

Field and perfect-record accuracy differ. With five required fields, one error on half the documents can coexist with 90% field accuracy. Measure records that proceed without material correction by document type and risk. Record sample size, language, vendor, scan quality, model and date; results without conditions are not reproducible.

Which work should the model interpret, extract and calculate?

Use the model for meaning and selection; use code for formal validation, arithmetic, identity and controlled writes. The border should follow what can be specified exactly.

A model can interpret “total due”, “balance payable” and “amount to be collected”, classify documents and identify conflicts. Structured output places candidates in named fields, but valid JSON does not prove semantic correctness. Google's guidance says to validate final values in application code.

Code should then:

• parse numbers according to declared locale and currency;
• preserve negative signs, decimal precision and original source text;
• validate real calendar dates and payment-term rules;
• compare duplicate identifiers;
• keep different currencies separate unless an exchange-rate source and date are defined;
• calculate from stored values; and
• enforce record schema, ownership and authority before a write.

If the model identifies R4 860,00 as amount due, locale-aware decimal code must convert it. Never turn invalid input into zero, strip a credit sign or assume currency merely to complete a record.

Why does source provenance matter as much as the number?

A business number is trustworthy only when a reviewer can identify its source, field meaning, version and transformation. The same digits can mean a subtotal, balance, credit, quote or amount already paid.

Each value should link to message, attachment, sender, received date and document, plus extraction version and correction state. “You owe R18,400” should open the contributing bills rather than demand faith in fluent prose.

Provenance makes correction possible. A replacement invoice can preserve both sources, identify the current version and recalculate. A disputed due date can be compared with the invoice date, service date and payment term.

The invoice extraction proof article owns the source-to-bill workflow. Every value affecting money, deadlines or client records needs evidence. A cited summary is not a durable record unless stored fields and calculations preserve that route.

How should deterministic calculations and records be designed?

Calculate from validated typed fields, state the inclusion rules and return both the result and its inputs. Reproducibility matters more than whether the interface appears conversational.

Use decimal-safe money representation and keep currency separate. Define whether totals include completed, cancelled, disputed or missing-date items. “What do I owe?” may include open bills and exclude paid ones, but the answer should state the rule and list records by currency.

Store due dates unambiguously only after establishing source meaning. “Net 30” needs a reliable starting date and calendar rule. Time zones belong to instants; an invoice due date may be a local date without a time.

Writes should be idempotent: reprocessing one source must preserve one source-linked record. Stable identifiers prevent exact-source duplication; commercial duplicates still require supplier, invoice number, amount and date comparison.

Test zero, credits, separators, decimal commas, malformed values, missing and mixed currencies and corrected records. Happy-path totals are insufficient.

How should uncertainty and correction work?

Material uncertainty should narrow the automated result and open a focused review; correction should repair the durable state and improve the test suite. A confidence score alone is not a control.

Confidence can prioritise review, but thresholds trade precision against recall. Google's Document AI guidance measures true positives, false positives and false negatives by field. Thresholds should follow consequence: newsletter classification and bank-detail changes have different error costs.

Name the issue: “The document shows 4,860 total and 4,228 before tax,” or “No currency is visible.” Put the source beside the record and leave unsupported fields empty. Confidence does not automate changed bank details, payment, accounting treatment or legal effect.

Correction must update the bill and future totals, preserve history where policy requires and become a regression case. Editing only the latest answer leaves the record wrong.

What does the current Digital Hank code prove about accuracy?

The code demonstrates useful separation and provenance, but it does not yet support a public numerical-accuracy claim. Several material validation paths require remediation and retained tests.

Communications are stored with the model version. Understanding uses constrained JSON, uncertainty and an instruction not to invent absent invoice fields. Stable source IDs prevent exact-source bill duplication. Ask groups open bills by currency and totals them in code. Contact extraction separately validates typed fields.

Automatic invoice materialisation writes model-extracted amount, currency and dueDate without a deterministic invoice validator. Manual parsing strips everything except digits and dots, risking credits and decimal-comma formats; invalid values can become zero. One path defaults unknown currency to ZAR. Due dates lack comprehensive source-backed validation.

These are code findings, not evidence of a deployed user error. The proof packet needs labelled invoices, credits, currencies, decimal formats, missing fields, replacements and duplicates; expected records; precision, recall and perfect-record rate; calculation and correction tests; and version metadata. Until then, no accuracy percentage may publish.

Who it is not for

This architecture is not a replacement for an accounting ledger, audit, tax advice or payment control. Firms with purchase-order matching, approval matrices, statutory reporting or high transaction volumes may need a specialised accounts-payable and document-processing system. The assistant can still capture and retrieve evidence, but the authoritative record belongs in the governed financial platform.

Stable machine-readable feeds should use deterministic import. Damaged scans, complex tables and professional judgement may need specialist review. The email-access safety guide remains relevant: accuracy neither cures weak validation nor grants authority.

Conclusion

AI assistants can handle business numbers reliably only when accuracy is engineered as a chain, not advertised as a personality trait. The model retrieves and interprets variable language; schemas constrain its candidates; deterministic code validates dates, currencies and formats, performs arithmetic and controls writes; provenance keeps every result connected to evidence; and focused review resolves material uncertainty. Measure source selection, classification, extraction, validation, calculation, duplication and final record correctness on a representative labelled set. Then keep corrections as regression tests whenever the model or pipeline changes. Digital Hank already has source-linked records and code-based totals, but current invoice validation and numeric parsing do not justify a public accuracy claim. The honest next step is remediation followed by reproducible field and perfect-record evidence—not a larger percentage in the headline.