Not “AI instead of accounting,” but a controlled invoice queue

Supplier invoices rarely arrive in one convenient template. Field positions, scan quality, line counts, language and attachment formats change. If automation depends on rules for each layout, every new supplier brings another configuration job. That is the operational problem described by Australia-based Ellby, a provider of document and invoice processing systems used by more than 400 organisations.

In an AWS case study, Ellby says it previously automated less than 60% of invoices, spent at least 24 hours configuring high-volume supplier profiles for each customer, and devoted more than 300 hours a month to template maintenance. After adding processing with Claude Sonnet and Haiku models through Amazon Bedrock, the company reports automation of more than 94% of invoices and a reduction of over 55% in customer onboarding time. These are one vendor's results on its own workload and under its own definition of “automation,” not a promise for another accounting team.

What actually matters in the case

Ellby did not give the model unconditional authority to post documents. According to AWS, the model extracts data from varied invoices; Ellby's proprietary rules engine then evaluates the output. Low-confidence documents are flagged for human review. This order matters more than the model's name: generation proposes structured fields, while business rules and an accountable employee govern acceptance.

For a smaller company, the principle becomes four stages:

  • An invoice enters a single register from email, electronic document exchange or scanning, retaining the source file and an identifier.
  • OCR and a model extract the supplier, tax identifier, invoice number and date, currency, line items, totals and tax fields — only the fields required by this workflow.
  • Validation compares those fields with the supplier record, purchase order, contract, arithmetic and duplicate rules. Missing or conflicting values are not guessed.
  • An accountable employee sees the source of each disputed value, corrects or rejects the invoice. Only an accepted result enters the accounting system, with an audit trail of actions.

This is our proposed adaptation of Ellby's principle, not a claim to document every internal component of its product. The 94% figure alone says nothing about errors among invoices accepted automatically; that needs a separate measure.

Data and integrations required

A pilot can begin with 100–200 recent invoices from different suppliers, together with the corrections accountants ultimately made. The sample must include not just clean PDFs but scans, multi-page documents, adjustments, unfamiliar layouts and duplicates. Otherwise the test measures only the easy portion of the workload.

The minimum integrations are a document source, a supplier master, purchase orders or contracts where relevant, a test accounting environment and a human-review queue. Cleaning supplier records and defining matching rules often takes longer than calling a model. A Russian business should establish which fields are mandatory in its accounting process, how exchange with 1C or another system works, and where financial data may be processed. The Australian infrastructure in Ellby's case is not an off-the-shelf answer to those questions.

A local model makes sense when documents must remain inside the organisation's environment, volume can justify the hardware and the chosen model has been validated on the organisation's own invoices. An API is simpler for small or irregular workloads, but data routing, contractual terms, availability and total processing cost still require assessment. RAG need not be the starting component: extracting fields from one invoice usually does not require retrieval. Searching contracts or procurement rules is useful when validation depends on other documents, provided the retrieved clause is shown to the reviewer.

Measure the outcome without fooling yourself

The key metric is not files processed but cost per correctly accepted invoice. Include OCR, model calls, rule checks, manual exceptions, integration, storage, quality control and maintenance. If the nominal automation rate rises while accountants spend more time hunting hidden errors, the economics worsen.

For an illustrative model, take 1,000 invoices a month. Suppose initial manual processing takes six minutes per invoice, or 100 hours. If 70% genuinely pass automated checks without correction and the remaining 30% still require six minutes each, about 70 hours of initial work are saved before sampling and support costs. This is a hypothetical calculation with explicit assumptions, not Ellby's result and not a forecast for the reader. Real measurements may differ.

Keep “field extracted,” “rule passed” and “document posted without error” as distinct measures. Track accuracy for critical fields, returns and corrections, time to acceptance, exception rate and cost by outcome. Ellby's figures appear in a case study from its technology partner AWS without a publicly available independent validation methodology. They are useful prompts for questions, not a transferable performance benchmark.

Keep a human in the loop where it matters

A wrong tax ID, date or amount may produce an incorrect posting or payment. Automatic acceptance should therefore be limited to pre-agreed cases: a known supplier, a matching order, reconciled arithmetic and no duplicate. New counterparties, changed payment details, unusual amounts and poor scans should enter an exception queue. NIST's AI risk-management framework emphasises defined human–AI responsibilities and evaluation throughout a system's life cycle; in document operations, this is a practical safeguard rather than paperwork.

A sensible first step is a two-week shadow run: AI fills the fields but posts nothing. Accountants compare its output with normal processing, record why results differ and build baseline metrics. Then the business can decide whether to automate a narrow supplier group, adjust its rules or stop using a model altogether. The lesson from Ellby is not a magical 94%; it is flexible extraction paired with verifiable rules and manageable exceptions.