What breaks when a Xero bank transaction doesn't match the bank statement line?
A BankTransaction created through Xero's API isn't automatically linked to the real bank statement line Xero later imports. Xero's schema tracks this with an IsReconciled flag; its auto-matching compares amount, date, and contact against imported lines, and if those don't line up closely enough, the created transaction and the real line both sit unreconciled instead of resolving into one record.
Part of the finance integrations guide.
| Symptom | A bank transaction created via integration and the real imported statement line both stay on Xero's Reconcile tab, unresolved |
|---|---|
| Root cause | A created BankTransaction and an imported statement line are separate objects until Xero matches them |
| What Xero matches on | Amount, date, and contact details, per Xero's own auto-matching behavior |
| Relevant field | IsReconciled (boolean) on the BankTransaction object |
| Where to check | The Reconcile tab for the specific bank account the transaction was created against |
Two separate records, not one
Xero's Accounting API exposes a dedicated BankTransaction object — with its own Type (RECEIVE, SPEND, and their overpayment/prepayment/transfer variants), BankAccount, and IsReconciled fields — that Loopfour's Xero integration can create, read, update, delete, and list. That's a genuinely richer surface than most of the other ERPs in Loopfour's integration set: NetSuite has no first-class payment object at all, and Sage Intacct splits AR and AP payments into separate objects with no bank-transaction concept. But a BankTransaction created this way is still just a record Xero knows about — it is a distinct object from the statement line Xero imports from the actual bank feed, and the two only become one reconciled entry once Xero matches them.
How Xero decides what matches
On the Reconcile tab, each imported statement line can be matched to an existing transaction in Xero, accepted from a suggestion Xero generates automatically, or turned into a brand-new transaction. Xero's auto-matching suggestions are based on amount, date, and contact details — the closer a created BankTransaction lines up with those three fields on the real statement line, the more likely Xero is to suggest (or automatically apply) the match. A transaction created with the wrong bank account, an amount that's off even slightly, or a date far enough from the real settlement date won't be offered as a match candidate, and has to be resolved manually.
What it looks like when this goes wrong
The visible symptom is duplication: the Reconcile tab shows both the transaction the integration created and the real imported statement line as separate, unreconciled items for what is actually a single real-world payment. If the created transaction is left in place and the real statement line is separately matched to something else (or reconciled as a new transaction), the account can end up double-counted until someone notices and manually deletes or voids the extra record — Xero's Status field distinguishes AUTHORISED, DELETED, and VOIDED for exactly this kind of cleanup.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Field mapping
Why a created transaction and an imported statement line diverge
A workflow creates a BankTransaction: Type=SPEND, BankAccount=the correct account, Date=the date the payment was initiated, Total=$3,150.00. Three business days later, the real bank feed imports a statement line for the same payment — but the settlement date on the bank's records is the date the payment cleared, not the date it was initiated, and the amount is $3,148.50 after a processor fee was netted out. Xero's auto-match compares amount and date between the two and doesn't find them close enough to suggest a match. Both records sit on the Reconcile tab: the created transaction (IsReconciled: false) and the imported statement line (also unreconciled), representing one real payment as two open items until someone manually matches them or corrects the created transaction's amount and date to reflect what actually settled.
Frequently Asked Questions
Sources
Related
Diagnostic
What causes a bank reconciliation to not balance?
In order of likelihood: a transaction was entered twice or not at all, an amount was transposed or mistyped, a bank fee or interest payment was never booked, a deposit in transit or outstanding check wasn't accounted for, or the beginning balance itself was wrong because a prior period's reconciliation was never actually correct.
Read moreTopic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreHow-to
How do I look up or update an AP bill in Xero?
Use getInvoice, updateInvoice, or listInvoices with the bill's InvoiceID — Xero has no separate Bill resource. A bill is an Invoice with Type=ACCPAY, and Loopfour's Xero integration exposes full get/update/list for Invoices generically. createBill is a convenience wrapper for creation only; reading and updating a bill happens through the Invoice actions, not a Bill-named one.
Read moreDiagnostic
What breaks when a reconciled Plaid transaction changes to modified or removed?
Plaid transaction data isn't immutable. A pending transaction can be removed from the feed entirely and replaced by a different transaction once it posts, and a bank can remove a transaction outright. If a payment was already matched to the old transaction, that match is orphaned the moment the removal comes through, and the replacement has to be found and re-matched — it doesn't update in place.
Read more