Sound familiar?
- Staff key supplier invoices into the accounts system line by line
- Every supplier's delivery note looks different, so template-based OCR keeps breaking
- Application forms arrive as scans and photos and are retyped into the CRM
- Contracts are signed and filed, but nobody can report on renewal dates or terms
- Errors from manual entry show up weeks later as mismatched stock or payments
- A backlog of paperwork grows every time someone is on holiday
Key facts
- Handles PDFs, scans, photos, Word files and email bodies, including multi-page and mixed batches
- Uses vision-capable language models plus OCR where needed, returning schema-validated JSON
- Every field is cross-checked against your own data, such as supplier records, PO numbers and totals
- Low-confidence or failed checks go to a review screen, not straight into your ledger
- Posts results to Xero, QuickBooks, Sage, your ERP, CRM or database through their APIs
- Original documents are kept and linked to each record for audit
- Retention, redaction and provider choice are designed around UK GDPR
Why template OCR stopped being enough
Traditional OCR turns an image into text, then relies on fixed templates or zones to find the invoice number or total. That works for one supplier's layout and breaks the moment they change it. Every new supplier means a new template.
Modern vision-capable language models from OpenAI, Anthropic Claude and Google Gemini can read a document much as a person does: they understand that "Inv No", "Invoice #" and "Our ref" might all mean the same thing, and they can pull line items out of a table that spans two pages. We ask the model to return JSON that matches a schema you agree with us, then validate it in code. For high-volume, consistent documents we may combine a dedicated OCR service with a smaller model to keep costs down.
Checks that catch mistakes before they cost you
Extraction is only half the job. The other half is proving the result is right before it reaches your ledger. Each document runs through rules such as:
- Line totals add up to the net total, and net plus VAT equals gross
- The VAT number and bank details match the supplier record you already hold
- The purchase order exists, is open and the quantities match what was received
- The same invoice number from the same supplier has not been processed before
- Dates are plausible and the currency is expected
Anything that fails a check or has low confidence goes to a review queue. A changed bank detail is always flagged for a person, because that is a common invoice fraud pattern.
The review screen
Reviewers see the original document on one side and the extracted fields on the other, with problem fields highlighted. They correct, approve or reject in a few clicks. Corrections are stored and fed back into the evaluation set, so we can measure accuracy by supplier and document type and improve the prompts where it matters most.
Over time the share of documents that pass straight through tends to rise, and your team's job changes from typing to checking exceptions.
Posting into your systems
Approved data is posted through the target system's API: the Xero API with OAuth 2.0, QuickBooks Online, Sage Business Cloud Accounting, KashFlow, your ERP or a custom database. We use idempotency keys and stored external IDs so a retry never creates a duplicate bill. The original file is attached to the record or linked from it for audit.
This is the same integration work we have done since the KashFlow and OpenCart days. If your accounting connection is the main need, see accounting software integration; for a wider view of paper-heavy processes, see workflow automation.
Starting with a sample of your documents
We do not ask you to take accuracy on trust. Early in the project we take a representative sample of your real documents, typically a mix of your most common suppliers or form types plus a few awkward ones, and agree the correct values for each field with your team. We then run the extraction pipeline against that set and report accuracy by field, by document type and by supplier.
That report shapes the build. It shows which fields can be trusted to pass straight through, which need a validation rule, and which document types should always go to review. It also gives a realistic estimate of running cost per document, so the business case is based on your paperwork rather than a vendor brochure. The same set becomes the regression test for every later change.
Data protection for documents
Documents often contain personal data, sometimes special category data such as health information on forms. We help you decide what is sent to a model provider, in which region and under what retention terms, and whether some document types should be redacted first or processed by an open-weight model on your own infrastructure. Retention rules delete or archive files on the schedule you set, and access to the review screen is role-based and logged.
Every document processing project is a fixed-price quote after a free chat, usually starting with a sample of your real documents so we can show accuracy before you commit to the full build.
What we deliver
- An intake route: shared mailbox, upload page, scanner folder or API endpoint
- Document classification to tell invoices from statements, credit notes and other paperwork
- Field extraction to a defined schema, including line items and tables
- Validation rules: totals add up, VAT is consistent, supplier and PO exist, no duplicates
- A review screen showing the document beside the extracted fields for quick correction
- API posting into your accounting, ERP or CRM system with idempotency
- Reports on volumes, accuracy, review rates and processing time
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
Can AI read handwritten or scanned documents?
Modern vision-capable models handle scans, phone photos and clear handwriting reasonably well, but accuracy drops with poor images and messy handwriting. dijitul developments tests a sample of your real documents first and routes low-confidence fields to a person, so poor-quality inputs are caught rather than posted.
Can extracted invoices go straight into Xero?
Yes. Approved invoices can be posted as bills through the Xero API with the original PDF attached. dijitul developments adds checks for totals, VAT, supplier details and duplicates first, and anything that fails goes to review. The same approach works for QuickBooks, Sage, KashFlow and most ERP systems.
How accurate is AI document processing?
It depends on document quality and variety, so we measure it on your own documents rather than quote a general figure. We build an evaluation set from real samples, report accuracy by field and document type, and use validation rules and human review to catch errors before they reach your systems.
What happens if the AI gets a field wrong?
Validation rules catch many errors, such as totals that do not add up or unknown suppliers, and send them to review. Reviewers correct the field beside the original document. Corrections are logged and added to the evaluation set, which helps dijitul developments improve accuracy on the documents that cause most trouble.
Is it safe to send documents to an AI provider?
It can be, under suitable processor terms, region and retention settings, which we check for the specific provider. For sensitive documents we can redact fields first or use an open-weight model on your own infrastructure. We document the data flows to support your DPIA.
How is document processing priced?
dijitul developments quotes a fixed price for the build after a free chat and a short test on sample documents. Running costs depend on volume and model choice; we estimate them from the sample and set spend caps. You own the code and the extracted data.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.