Why Xero won't import received payments (and what bookkeepers do instead)
If you have gone looking for a way to import a file of received payments into Xero the way you import invoices or bank statements, you have found the gap and probably the long-running community thread about it. The short version: Xero has publicly said it does not plan to support importing received payments. This article explains what that means in practice and the workflows bookkeepers actually use to work around it.
What you can and cannot import
Xero is generous with imports in some directions and closed in others. You can import a bank statement as CSV. You can import sales and purchase invoices. What you cannot do is take a file that says these customers paid these amounts against these invoices and have Xero apply those payments in bulk. Payment application is a screen task, not an import.
Why the gap exists at all
Applying a payment is a decision, not just a data load. When a customer pays a lump sum, someone has to decide which invoices it clears, whether any were short-paid, and how credit notes fold in. An import format would have to encode all of those decisions correctly, and a wrong import silently mis-applies money against the wrong invoices, which is worse than no import at all. The bank reconciliation and batch tools exist so a human makes that call with the totals visible.
What bookkeepers do instead
1. Match on the bank reconciliation screen
For clean payments, Find & Match on the Reconcile tab is the fastest native route. Tick the invoices a deposit covers and reconcile in one action. It works well when each invoice is paid in full and the count is modest.
2. Record batch deposits
For a payment run, select the invoices and record a batch deposit, remembering the 50-invoice-per-batch cap. Beyond 50 invoices you split into multiple batches and reconcile the single bank line across them.
3. Push payments through the API
Where the volume justifies development, the Xero API can create payments and batch payments programmatically. This is the closest thing to an import, but it is a build, not a button, and the Batch Payments API caps a batch at 200 lines. Most bookkeeping practices do not have the engineering time to maintain this against a moving API.
4. Use a purpose-built matching tool
The pragmatic answer for high-volume AR is a tool that does the decision, matching a remittance to open invoices, and then uses the supported batch-payment path to post the result once a human approves. This respects Xero's design: the tool makes the allocation reviewable, and Xero still receives the payment through its own sanctioned mechanism.
Planning around the gap
The received-payments import is not coming. That is not a reason to keep opening invoices one at a time forever; it is a reason to move the effort to where it belongs, which is deciding the allocation quickly and correctly, then letting Xero record it through the batch path it already supports. The gap is real, but it is a matching gap, not a data-entry gap, and it is the matching that is worth solving.
Have a remittance that never ties out cleanly? Email one redacted copy plus an export of your open invoices to support@remitmatch.app and we will send back a free matched report, line by line, balanced to the cent, within 48 hours.
Email support@remitmatch.appFree matched report
Prove us wrong with your worst remittance.
Email one redacted remittance and an export of your open Xero invoices. We send back the matched report, line by line, balanced to the cent, within 48 hours. Free.
Email support@remitmatch.app