The Xero 200-invoice batch payment limit: why mega-batch remittances break reconciliation

You open a remittance from one of your biggest customers. It covers 500 invoices across the last fortnight. You try to post it as a batch payment in Xero and get the error: "A batch payment cannot contain more than 200 payments." Welcome to one of the most frustrating ceilings in the Xero ecosystem.

The 200-invoice cap on Xero batch payments is real, it is enforced at the API level, and it cannot be lifted by support, by your Xero partner, or by any app in the marketplace. If a single customer pays you against more invoices than that in one remittance, you are going to have to change something in your process. This post walks through what the limit actually is, who hits it in practice, the workarounds available, and how to decide which one fits your business.

What the 200-invoice limit actually is

Xero's batch payment feature lets you group multiple sales invoice payments into a single bank transaction. It is the natural Xero-side counterpart to a customer remittance: one deposit on the bank statement, many invoices marked paid. The cap is a hard constraint: a single batch payment cannot reference more than 200 invoices. The same limit applies whether you build the batch manually through the Xero UI, import it via CSV, or post it through the Xero Payments API. Xero support has confirmed this is enforced at the platform level.

The cap is not a bug, it is a performance and data-integrity decision on Xero's side. But the consequence is that any customer who pays you against more than 200 invoices in a single remittance has broken your one-to-one mental model of "remittance equals batch payment."

Who actually hits this in the UK and Australia

Most Xero users never bump into the 200 cap, which is part of why it is such a shock when it happens. The people who do hit it cluster into a few predictable profiles.

Facilities contractors paid by grocery chains

A mid-size facilities or utilities supplier serving a national grocer is the textbook case. One real pattern from the field: a contractor invoicing each store in a supermarket estate individually, then receiving a single remittance covering every store-level invoice for the period. When the customer is a brand like Morrisons, Asda, Sainsbury's, or Tesco and the supplier is posting one or two invoices per store per week, you can cross 500 invoices in a single remittance without doing anything unusual. A real pipeline example: a single Morrisons remittance to one facilities contractor can carry between 500 and 900 invoices.

Multi-entity labour hire and civil contractors

Labour hire firms in civil and mining (particularly in Australia) invoice major principal contractors weekly for each placement. A major principal contractor might pay a single weekly remittance that clears 200 to 500 separate invoices, one per person per project. Retentions and partial payments make these remittances even harder to reconcile, because the remittance total does not match the gross invoice total. One contractor in this vertical runs around 400 remittances per month across 8 Xero entities, with the largest single remittance sitting above 500 lines.

NDIS providers receiving NDIA bulk remittances

NDIA payments to providers are the Australian disability sector's version of the same structural problem: the agency pays in bulk against many participant-level invoices on a fortnightly cycle. Larger providers routinely receive remittances of 200-plus lines. This also applies downstream to plan managers, who consolidate service-provider invoices and pay them on behalf of participants. We cover this case in depth on the NDIS remittance reconciliation solution page.

Wholesale and distribution suppliers

Any wholesale supplier with weekly invoicing to a handful of large retailers or chain customers sits in the danger zone. You do not need to be enterprise-scale. A £2-5m-turnover wholesaler with one or two chain customers paying fortnightly across every depot can easily land a 250-line remittance and discover the cap.

The four ways people deal with it

Once you accept that one remittance cannot become one Xero batch payment, the question becomes which compromise you are least unhappy with. Four practical options:

1. Split the remittance into 4 (or more) batch payments. The standard Xero workaround. You take a 600-invoice remittance, break it into three groups of 200, and post three separate batch payments summing to the total. The bank transaction line still needs to be reconciled against the sum, so you end up allocating the deposit across multiple Xero receipts. Workable if your team accepts the extra steps and the audit trail is clean. Painful if the CFO expects a single reconciled receipt matching the single bank credit.
2. Invoice in aggregate instead of per-line. Some suppliers dodge the problem by consolidating multiple services into summary invoices, so the count per remittance stays under 200. This only works if your customer will accept the aggregated format. Most chain retailers and principal contractors insist on line-item invoicing for their own reasons (cost coding, internal approvals, retention tracking), so this is rarely a real option.
3. Reconcile the deposit as a single receipt and then allocate invoices manually. Rather than use batch payments at all, some teams post the remittance as a lump-sum customer prepayment, then apply it to invoices one receipt at a time. This gets you the single-receipt reconciliation the CFO wants, but it destroys any audit trail that ties the specific invoice lines to the remittance PDF. It also becomes administratively heavier as invoice counts grow.
4. Automate the matching and accept the split. The pragmatic path for most high-volume teams. You accept that Xero will need multiple batch payments for a single customer remittance, but you remove the manual cross- referencing that eats hours every week. Tools that match remittance PDFs to open Xero invoices automatically (by invoice number, amount, and reference) can do in 30 to 60 seconds what a bookkeeper does in 2 to 4 hours, and then post the resulting batches back to Xero in one click, respecting the 200-line split automatically.

How to decide which route fits you

There is no universal right answer. The decision is driven by three things: who owns the reconciliation, how much your finance team's time is worth, and how strict your audit requirements are.

Start with volume. If you are running 10 or fewer oversized remittances per month, splitting manually is annoying but survivable. If you are running 50 or more, the cumulative time cost makes automation the obvious call. A finance manager spending 2 hours per mega-batch remittance at 50 per month is giving up 100 hours a month, which at a £40,000 fully-loaded bookkeeper salary is around £2,000 a month of time, or close to £25,000 a year.

Then consider the receipt structure your CFO expects. Some finance leaders insist on a single bank receipt matching one reconciled document. Others are perfectly comfortable with a remittance that splits into 4 batches as long as the total reconciles to the deposit and the PDF sits against each batch as evidence. This preference is usually the deciding factor between options 3 and 4 above. If you are in a fit-for-audit environment (grant-funded, NDIS billing, public-sector contracts) you will want the audit trail that comes from linking remittance documents directly to the batch payments.

Finally, check your contract structure. If you have one or two very large customers generating 90 percent of the mega-batches, it is worth a quiet conversation with their AP team about how they build the remittance. Some will agree to send a remittance per depot, per week, or per cost centre, which keeps individual counts below 200 without changing your invoicing. Others will not move. Knowing which is which saves you trying to fix the problem on the wrong side.

When the 200 limit is a signal to walk away from Xero

Rare, but worth saying out loud. If a single customer routinely sends you remittances of 1,000-plus invoices, and your CFO will not accept any form of split-receipt reconciliation, and the customer will not change their remittance format, you may simply have outgrown Xero for that workflow. Most businesses who hit this are at the upper end of Xero's natural fit and are often already evaluating NetSuite or similar. Hitting the batch cap is not the reason to migrate, but it is a useful forcing function to check whether you are at the platform boundary for other reasons too.

How RemitClear handles the cap

One soft product note, because it is directly relevant. RemitClear reads the remittance, matches every line against open Xero invoices, and posts the result back as a Xero batch payment (or multiple batch payments split at the 200-line boundary where required), with the original remittance PDF attached to each batch. You still end up with more than one Xero transaction for a 500-line remittance, but the manual cross-referencing disappears and the audit trail is clean. For teams who can live with a multi-batch receipt, it is the fastest path. For teams who insist on one-receipt-per-remittance regardless of line count, Xero itself is the constraint, and no Xero add-on can fix it.

Summary

The 200-invoice batch payment cap is a Xero platform limit that mostly bites businesses with concentrated customer bases and high invoice frequency: grocery suppliers, labour hire firms, NDIS providers, and wholesale distributors. You have four realistic options: split the batch, aggregate the invoicing, reconcile as a lump-sum prepayment, or automate the matching and accept a multi-batch posting. The right choice depends on volume, CFO preferences, and audit requirements. If you want to read more about the underlying reconciliation workflow, see our guide on how to reconcile remittance advice in Xero, or the solution page for multi-invoice payment matching in Xero. If your AR work currently sits with an offshore team, our breakdown of offshore AR teams versus Xero automation covers when the maths flips toward bringing matching back in-house.