Xero and CodeWords: bank reconciliation and the accountant relationship

Xero's centre of gravity is the bank reconciliation screen. Transactions arrive from the bank feed, Xero suggests matches, and somebody works through the queue deciding what each one is. For most small businesses that screen is the accounting process, and the length of the queue is the honest measure of how far behind the books are.

So the automation worth building around Xero is mostly about that queue: making it shorter, making the suggestions better, and making the exceptions visible. Notably, it is not about coding transactions automatically, for reasons the next section covers.

What we'll cover

• Why the reconciliation queue is the thing
• What the Xero API reaches
• Connecting it to CodeWords
• Eight automations worth building
• Keeping your accountant able to work
• Multi-currency, which needs deciding first
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why the reconciliation queue is the thing

It is where the backlog lives. Unreconciled transactions are the visible measure of how out of date your accounts are, and everything downstream — reporting, tax, cash position — is wrong while they sit there.

Most of it is repetitive. The same supplier, the same amount, the same account, every month. Xero's bank rules handle some of this natively and should be used for it.

The exceptions are where judgement is needed. A payment that does not match anything, an amount slightly off, a transaction from a supplier you do not recognise. These are a small proportion of the queue and most of the time spent on it.

Nobody enjoys it. Which is why it gets postponed, which is why the queue grows, which is why the accounts are two months behind when somebody needs a number.

Automation helps by shrinking the routine portion and surfacing the exceptions as a short list rather than leaving them mixed in with everything else.

What the Xero API reaches

Bank transactions and bank transfers can be read and created, which covers the money movement side.

Invoices and bills can be created, read, updated, and voided, with line items, tracking categories, and tax rates.

Contacts can be read and written, including their default accounts and payment terms.

Payments can be created against invoices and bills, which is how a receipt gets applied.

Accounts — the chart of accounts — can be read, which anything coding a transaction needs.

Tracking categories are Xero's dimension mechanism for departments, locations, or projects, and they are frequently the reason a report is useful or useless.

Reports can be run, returning the same figures the interface shows.

Webhooks notify on changes to invoices and contacts, so an automation can react rather than poll.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, being explicit about what it prepares and what, if anything, it may create.
3. Authorize the connection through Xero's OAuth flow, against a demo organization first.
4. Describe the exceptions: an amount that does not match exactly, a contact that does not exist, a transaction in a foreign currency.
5. Reconcile its output by hand for a full period before trusting it once.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Eight automations worth building

Exception surfacing from the reconciliation queue. Read the unreconciled transactions, apply your own matching logic against invoices and known suppliers, and produce a short list of the ones that genuinely need a decision. The routine ones are what Xero's bank rules are for; this finds the rest.

Invoice creation from another system. Draft invoices assembled from your CRM, your project tracker, or your usage data, with lines and tracking categories filled in, ready for review.

Supplier bill capture. Bills arriving by email, read, with supplier, amount, date, and suggested account extracted, created as drafts for approval.

Overdue chasing. Identify overdue invoices, check they have not in fact been paid, and prepare the chase. Cap the sequence and hand to a person rather than chasing indefinitely.

Reconciliation against other systems. Xero against your payment processor, your store, and your bank statements, with differences reported. This is where real discrepancies surface.

Recurring transaction verification. Confirm the things that should happen monthly actually did. Absence is the failure nobody alerts on.

Tracking category hygiene. Transactions coded without a tracking category, or to a category that is no longer used, reported weekly. Reports built on inconsistent tracking are quietly wrong.

Cash position reporting. Balances, upcoming bills, expected receipts, and the resulting picture, delivered where you will see it rather than assembled when somebody asks.

Keeping your accountant able to work

This is the part that separates automation that helps from automation that creates work for somebody else.

Leave an audit trail with reasons. Every transaction an automation created or coded should carry a note saying what decided it. Your accountant's job at year end is to understand what happened, and a ledger full of entries with no explanation makes that harder rather than easier.

Do not invent contacts. An automation creating a new contact for every slightly different supplier name produces a contact list nobody can use and reports that split one supplier across four rows. Match conservatively and flag the ambiguous.

Respect the lock date. When a period is locked, it is locked deliberately. An automation attempting to post into it should stop and report rather than retry.

Keep tracking categories consistent. They are what makes departmental and project reporting possible, and an automation coding without them is quietly degrading every report built on them.

Talk to them before you build. Ten minutes with whoever does your books will tell you which parts of the queue are genuinely mechanical and which require judgement they would rather keep. That conversation is cheaper than discovering the answer through a year-end correction.

Multi-currency, which needs deciding first

If you invoice or pay in more than one currency, settle these before automating anything that creates transactions.

Which rate, from when. Xero applies rates by date, and the date used for an invoice, a payment, and a reconciliation may differ. Those differences produce realised gains and losses that land somewhere in your accounts.

Where gains and losses go. This is an accounting decision with tax consequences, and it should be made by whoever is accountable for the accounts rather than inferred by an automation.

Bank accounts have currencies. A payment into the wrong currency account is a correction rather than an edit.

Reporting currency is not transaction currency. A report in your base currency is converted, and an automation comparing a converted figure against a source-system figure in the original currency will never reconcile.

Where you trade in one currency, this section is irrelevant and you can skip it entirely. Where you do not, it is the most common source of accounting automation that produces plausible, wrong numbers.

Building it so it survives

Make it safe to run twice. Creating a duplicate invoice in a ledger is a real problem. Check for an existing document with the same reference before writing, using a reference derived from the source system rather than generated fresh.

Treat ambiguity as a reason to stop. A payment matching two invoices equally well belongs on the exception list, not applied to whichever sorted first.

Log every created transaction with its reasoning. This is not optional for anything touching a ledger, and it is the first thing anyone asks for when a figure is questioned.

Use a demo organization for testing. Xero provides one. There is no reason for the first run of an accounting automation to be against real books.

Send a daily summary. What was prepared, what was created, what needs attention. An automation touching your accounts that nobody supervises is a bookkeeper nobody supervises.

Limits worth knowing about

Rate limits apply per tenant and per app, with both a per-minute and a daily ceiling, so bulk operations need pacing rather than a tight loop.

OAuth tokens expire and need refreshing, and the connection is per organization, so a multi-entity setup needs that handled explicitly.

Lock dates reject writes, correctly. Handle it as a business case rather than an error.

Tax rates are jurisdictional and specific. An automation creating invoices must have the tax treatment specified rather than inferred, and a small error compounds quietly across many transactions.

Attachment size and count limits apply, which matters for anything filing receipts against transactions.

What to build first

Exception surfacing from the reconciliation queue, read-only. It needs no write access, it produces a short list that is immediately useful, and it tells you what proportion of your queue is genuinely mechanical — which is the number that decides whether anything else here is worth building.

Two habits make the difference. Run it alongside a period of manual reconciliation and compare what it flagged against what actually needed a decision. And have it report even when the exception list is empty, because a silent check cannot be distinguished from a broken one.

Frequently asked questions

Should an automation reconcile transactions automatically?

Use Xero's own bank rules for the genuinely repetitive ones — they are native, visible in Xero, and your accountant can see them. Reach outside for the exceptions, and surface those rather than resolving them. The exceptions are where judgement lives, which is precisely why they are the ones left over.

Can it create invoices?

Yes, and drafts for review are the better arrangement for anything where the amount or the coding involves a decision. Invoices assembled from a system that already knows the amounts, such as usage data, are a reasonable candidate for creating directly, with a daily summary of what was created.

How do I avoid duplicate invoices?

Give every invoice a reference derived from the source record rather than generated fresh, and check for an existing document with that reference before creating. Webhooks retry and people click twice, so this is the guard that matters most.

What happens if the period is locked?

Xero rejects the write, which is correct. Route the transaction to a person to decide where it belongs rather than treating it as a technical error to retry.

Will this annoy my accountant?

Not if it leaves an audit trail with reasons, matches contacts conservatively, and respects lock dates and tracking categories. What annoys accountants is a ledger full of entries with no explanation and a contact list containing one supplier four times. Both are avoidable at design time.

How should I handle multi-currency?

By deciding the treatment explicitly — which rate, from what date, and where gains land — with whoever is accountable for the accounts. An automation that infers these will be consistently wrong in a way that looks plausible for months.

Can I connect Xero to my payment processor?

Yes, and the reconciliation automation is the read-only version worth starting with: compare what the processor says against what Xero holds and report the differences. That alone usually finds something, and it involves no write access at all.

How do I handle supplier names that never match?

Maintain a mapping from the variants that appear on your bank feed to the contact in Xero, and have the automation consult it rather than matching on text each time. Bank descriptions are inconsistent in ways no fuzzy match handles reliably, and a mapping you extend when something new appears converges quickly.

Can it help with VAT or sales tax returns?

It can assemble the figures and flag transactions coded to unexpected tax rates, which is genuinely useful preparation. Filing is a decision with legal consequence and belongs with whoever is accountable for it.

Related reading

• QuickBooks and CodeWords
• FreshBooks and CodeWords
• CodeWords integrations and templates