Automate Invoice Data Entry into Xero with OCR

What OCR Xero already has (Hubdoc) and its limits

If you use Xero, you already have some OCR built in. Xero bundles Hubdoc, a document capture tool that reads supplier invoices, receipts and statements. You forward a PDF by email, upload a photo, or connect a supplier so documents arrive automatically. Hubdoc then extracts the key fields, typically the supplier, date, invoice number and total, and creates a draft transaction inside Xero with the original document attached.

For a bookkeeper handling a modest pile of bills each month, that is often enough. The capture is decent, the source file travels with the record, and nothing posts to your ledger without a human clicking through.

The limits show up as volume and complexity grow. First, extraction lives inside Xero. Hubdoc is designed to feed Xero, so the data it reads is not something you can easily reuse elsewhere, in a spreadsheet, a separate approvals tool, or a second accounting system. Second, you get Hubdoc's field mapping, not your own. If you want a specific tax rate applied to a supplier, a tracking category set by rule, or a line description reformatted, you are working within what the tool exposes. Third, and this is the one that surprises people: there is no public Xero OCR API. You cannot call Xero's OCR engine from your own software and ask it to read a document. Capture is a product feature, not a service you can automate around.

How OCR data feeds Xero: the Accounting API (bills)

So if you cannot call Xero's OCR, how does automated invoice data get in? You do the extraction yourself, or with a separate OCR service, and then push the finished data into Xero through the Accounting API.

A supplier invoice in Xero is an accounts-payable bill. In API terms it is an Invoice record with the Type set to ACCPAY. (Sales invoices you send to customers use Type ACCREC, which is a common source of confusion.) You create the bill by sending the fields you have already extracted: the contact, the date and due date, one or more line items with amounts and account codes, and the tax treatment.

The order of operations in a typical flow looks like this:

1. A document arrives (email, upload, or folder) and an OCR step reads the fields.
2. Your flow matches the supplier to an existing Xero contact, or creates one.
3. It maps the extracted amounts to the right account codes, tax rates and, if you use them, tracking categories.
4. It creates the bill as a DRAFT via the Accounting API.
5. It attaches the original invoice file to that bill using the Attachments endpoint, so the source document is one click away.

This is the same shape of pipeline whatever your OCR engine is, and it is worth understanding the fundamentals before you build. Our overview of OCR for accounting walks through what OCR can and cannot reliably read, which is the part that determines how much review you will need at the end.

Import options: API vs Hubdoc vs e-invoicing (PEPPOL)

There are three broadly different ways to get supplier bills into Xero, and they suit different situations.

Hubdoc is the low-effort option. No development, no API keys; you forward documents and review the drafts. It is a sensible default for lower volumes and straightforward invoices.

The Accounting API is the route when you want control. You, or a partner, build a flow that extracts, validates and posts bills on your terms. This is where custom field mapping, your own duplicate checks and a single pipeline across several tools become possible. It is more work to set up and it needs maintaining, but it fits businesses whose invoice handling has outgrown a forward-and-review inbox.

E-invoicing over PEPPOL is different in kind: instead of reading a PDF, the invoice arrives as structured data, so there is no OCR and no guesswork about fields. Xero supports e-invoicing over the PEPPOL network, and where it is available it is the cleanest option because the data is machine-readable from the start. In practice, coverage is strongest in Australia, New Zealand and the UK. Across continental Europe, including the Baltics, adoption is growing but not universal, so for many EU readers PEPPOL is a welcome bonus when a supplier supports it rather than the route you can rely on for every bill. Because e-invoicing mandates are moving quickly in the EU, treat this as something to check for your country and suppliers rather than assume.

Most real setups end up as a mix: PEPPOL where a supplier offers it, OCR-plus-API for the PDFs and scans that make up the rest.

Draft bills and the review workflow before publishing

Whatever route the data takes, the safest pattern is the same one Hubdoc uses: create bills as drafts and let a human approve them before they post. OCR is good, not perfect. A stray character in an invoice number, a total read from the wrong box, or a supplier matched to the wrong contact are the kinds of errors that are cheap to catch at review and expensive to unpick once posted.

A workable review workflow keeps the person in the loop only where it adds value:

• The flow posts a draft bill with the source document attached, so the reviewer sees the original and the extracted data side by side.
• Automated validation rules flag anything that looks off before a human even looks: totals that do not match line items, a missing tax rate, a due date in the past, or a supplier the system has not seen before.
• Clean, high-confidence bills from trusted suppliers can be surfaced for a quick glance; anything flagged gets a closer look.
• The reviewer approves, which publishes the bill, or corrects and re-checks.

The goal is not to remove the human. It is to make sure the human spends their attention on the handful of bills that need judgement, rather than re-typing the ninety that were fine. Keeping drafts as the default is what makes automation safe to trust.

When a custom OCR flow beats Hubdoc

Hubdoc is a good tool. The honest position is that it is fine for simple cases and starts to hold you back in specific ones. A custom OCR flow is worth the extra effort when one or more of these is true.

You run more than one system. Hubdoc feeds Xero. If the same invoices also need to reach an inventory tool, a project system, or a second set of books, a custom pipeline lets you extract once and send the data to each destination, rather than capturing the same document several times.

You need your own review and validation rules. With your own flow you decide what counts as suspicious, which suppliers auto-approve, and what gets held back. Those rules encode how your bookkeeper actually works, rather than a generic default.

You need precise field mapping. If tax rates depend on the supplier and the expense type, or tracking categories must be set by rules that reflect your reporting, a custom flow lets you map every field deliberately before the bill is created.

Your volume justifies it. At higher volumes the time saved on consistent, rule-driven handling outweighs the setup and maintenance cost.

The same logic applies across accounting platforms, not just Xero. If you also work in the QuickBooks world, our guide to pushing OCR invoices into QuickBooks Online covers the equivalent flow there. Features on both platforms change, so it is worth confirming current API behaviour before committing to a build.

Mistakes to avoid (tracking categories, tax rates, duplicates)

A few mistakes come up again and again when automating bills into Xero. None is hard to avoid once you know to look for it.

Guessing tax rates. A wrong tax rate quietly distorts your VAT position and is tedious to correct across many bills. Map tax rates explicitly, usually driven by the supplier and the expense account, and flag anything the flow is not confident about for human review rather than defaulting silently.

Getting tracking categories wrong, or ignoring them. If you use tracking categories in Xero for departments, locations or projects, they should be set by clear rules, not left blank or filled in by guesswork. Blank tracking on posted bills means your reports quietly lose detail that is hard to rebuild later.

Creating duplicates. The same invoice can arrive twice, forwarded by email and also picked up from a folder, for example. Without a check, you post it twice. Build a duplicate check on a stable combination such as supplier plus invoice number plus amount, and hold suspected duplicates for review instead of posting them.

Mismatching contacts. Automatically creating a new contact for every slight spelling variation leaves you with several versions of one supplier. Match against existing contacts first, and only create a new one when there is genuinely no match.

Posting straight to approved. Skipping the draft stage to save a click removes your safety net. Keep bills as drafts until a person has approved them, especially early on while you are still learning where your OCR and mapping get things wrong.