What does payment amount exceeds the amount outstanding mean in Xero?

It means Xero was handed a payment worth more than the invoice it names still has owing, and refused it. Zanda states the underlying rule as overpayments not being permitted by Xero, meaning payments worth more than the invoice amount. The invoice is untouched by the refusal, and the payment does not land.

Why does a Stripe processing fee cause this error?

The fee is added to the invoice in the practice software after that invoice has already gone to Xero. Taking a card payment with the processing fee setting on adds a fee line, which lifts the practice software total to match the fee inclusive payment. Xero is still holding the older, lower total, so the payment arrives worth more than the invoice.

Can I edit the Xero invoice to add the fee?

Not while a payment or a credit note sits against it. Amounts and quantities are the fields that need the payment removed first, so a fee line cannot be added to a settled invoice, and the write comes back as a status error instead. Zanda's answer for an invoice already across is to export the payment at the value Xero holds and post the fee separately.

How do I stop it happening on the next batch?

Change when the invoices go across. Exporting invoices as late as possible, after any card payment and its processing fee have been taken, means the invoice and the payment reach Xero already agreeing. Zanda gives that as the way to avoid it for future invoices, and it costs nothing to change.

Our payment is in the practice software but Xero does not have it. Same problem?

That is usually a different failure. Cliniko sends a payment only once it has been allocated to an invoice, so an unallocated payment is not seen in Xero, and a payment made from account credit is not accepted by Xero at all. That leaves an open invoice with no error attached, rather than a refused payment.

Where should the excess money sit if it cannot go on the invoice?

The excess sits against the payer rather than against the document. Xero holds an excess as its own object that can be applied to a later invoice or refunded, and the canonical templates hold money taken before a session as a liability until a session uses it. Which of the two applies depends on whether an invoice existed when the money arrived.

Problems

Payment amount exceeds the amount outstanding

Xero refused the payment because it is worth more than the amount still outstanding on the invoice it was aimed at, and Xero does not accept a payment larger than the invoice it settles. Two different things put it there: a card processing fee added to the invoice after that invoice went to Xero, and money that really is in excess. Only one of them is fixed in Xero.

Key facts

The message: Payment amount exceeds the amount outstanding on this document.¹
The rule underneath it: Zanda states it plainly: overpayments are not permitted by Xero, meaning payments worth more than the invoice amount²
The common cause: A Stripe card processing fee added to the invoice in the practice software after that invoice had already been exported to Xero and approved, which raises the practice software total above the Xero one¹
Why the invoice cannot be raised to match: An invoice amount is one of the fields Xero will not change while a payment or a credit note is allocated to it, so the older, lower total is the one the payment is measured against¹
Which batch it fails on: The second one. Zanda exports in two batches, invoices first and payments after, so the invoice lands and the payment behind it is the thing refused²
Zanda's repair for an invoice already across: Export the payment at the invoice's own recorded value in Xero, excluding the fee, then record the processing fee separately as a bank or processing fee expense reconciled through the same payments clearing account¹
Zanda's way of stopping it: Export invoices as late as possible, after any card payment and its processing fee have been taken, so the invoice and the payment reach Xero already matching¹
Where the fee sits in the canonical template: The allied health template posts a card processing fee to Merchant and claiming fees at 604, with the charge itself running through Online payments clearing (Stripe) at 107⁴
The other vendor's version: Cliniko sends a payment only once it is allocated to an invoice, so an unallocated payment is not seen in Xero at all, and a payment made from account credit is not accepted by Xero³

What the message is telling you

Nothing is wrong with the invoice on the screen in front of you. Xero was handed a payment and measured it against what it still has outstanding on the document that payment names, found the payment bigger, and refused the write. The invoice stays where it was and the payment does not land.

The sentence withholds the one thing that would settle it, which is why the two figures are apart. Either the invoice moved on one side after the batch started, or the money coming in was larger than the invoice from the beginning. Working out which of those you have is the whole diagnosis.

Two causes under one sentence

The refusal reads the same either way, so the useful split is by what raised the payment above the invoice. One of these is repaired in Xero. The other is repaired by changing the order the export runs in, which is why reaching for Xero first can cost an afternoon.

Where you met it, what is out of step between the two ledgers, and where the repair sits¹²³

Where you met it	What is out of step	Where the repair sits
Zanda, on the payments batch	A card processing fee was added to the invoice in Zanda after that invoice had already been exported to Xero and approved	In the export order rather than in Xero, plus a separate line for the fee on the invoices already across
Zanda, on the payments batch	The money is genuinely worth more than the invoice, which Xero does not take as an invoice payment	In Xero, where the excess becomes its own object against the payer
Cliniko, on money held as credit	Nothing is exported at all: an unallocated payment stays in Cliniko, and a payment made from account credit is not accepted by Xero	In Xero by hand, and in the account that holds client money until a session uses it

The fee line added after the export

This is the case Zanda names first, and it is the one that catches practices taking card payments online. With the card processing fee setting turned on, taking a payment adds a fee line to the invoice in the practice software, which lifts that invoice's own total so it matches the fee inclusive payment. Inside the practice software the two agree.

This happens when the payment you are exporting is worth more than the invoice's total already recorded in Xero. The most common cause is a Stripe card processing fee added to the payment after the invoice was already exported and approved in Xero.¹

The order is what does the damage. If the invoice went across before the fee existed, Xero is holding the original, lower total, and the payment that arrives afterwards is carrying a fee Xero has not seen. The practice software is right, Xero is right, and the two are describing different documents.

Why the invoice cannot just be raised to match

The obvious move is to add the fee to the Xero invoice and re-run the batch. That works only while nothing has been allocated to the Xero invoice. Adding a line changes the amount, and an amount is one of the fields that needs the payment or credit note taken off first, which is the same rule that produces invoice not of valid status for modification from the other direction.

So a practice that already exported one part payment against the invoice, then took the balance on a card with a fee on it, is holding an invoice Xero will not edit and a payment Xero will not take. Neither side gives, and the repair has to go around: send the payment at the value Xero has, and give the fee its own line rather than trying to fold it into a closed document.

When the money really is more than the invoice

The second cause has nothing to do with fees. Someone paid a round figure, or paid for a block of sessions against the first invoice in it, or a payment was taken twice and both copies were allocated. Zanda states the constraint without qualification: overpayments are not permitted by Xero, meaning payments worth more than the invoice amount.

Excess money still has to live somewhere, and in Xero that somewhere is an object against the payer rather than a bigger payment against the invoice. Reconcile an overpayment in Xero walks through the posting and what it does to the bank line. Cliniko practices meet the same money in a different shape, because a payment made from account credit is not accepted by Xero at all and the invoice behind it stays open, which is invoices paid by account credit stay open in Xero.

A client pays a round figure and leaves the change on their file. The excess is not part of the invoice, so it cannot ride on the invoice payment.
A package or a block of sessions is paid up front and allocated against the first invoice raised. Only the first session has been supplied, so only that invoice can take a payment.
The same card payment is recorded twice in the practice software and both copies are picked up by the export, which leaves the second one with nothing outstanding to settle.
A credit note in Xero has already reduced what is owing, so a payment exported at the original invoice value is now larger than what is left.

The last two are the ones to test rather than assume. None of the vendor articles read for this page names them, so they are listed here as routes worth checking on your own file and they are carried in the open questions below rather than stated as causes.

What the refused payment leaves in the ledger

A refused payment is quieter than a failed sync, because the invoice did land. Revenue is posted, the client shows as owing, and nothing in Xero says a payment was ever attempted. The practice software shows the invoice settled. The two ledgers now disagree by exactly the payments that were refused, and the first person to notice is usually whoever is chasing debtors.

Plate 1The same four accounts, while the payment is refused and after it and its fee are posted.

The settlement is the part that stings. The processor pays out net of its fee on its own schedule, so a bank line arrives for money the ledger has no payment behind. Matching it means a manual receipt against an invoice the bookkeeper has to go and find, one client at a time, and the difference between the gross charge and the payout has to be posted as the fee it is.

Clearing it, in order

Open the invoice in Xero and read its total and its amount outstanding, then read the payment the practice software is trying to send. The gap tells you which cause you have.
Where the gap is a card processing fee, leave the Xero invoice alone. Its amount cannot move while anything is allocated to it, and forcing it produces a second error rather than a fix.
Export the payment at the value Xero holds for the invoice, so the invoice closes on the figure it was approved at.
Post the fee on its own line as a processing fee expense, which is Zanda's own repair, reconciled through the same payments clearing account the card and terminal settlements go through, so the payout still reconciles to one bank line.
Where the gap is real money rather than a fee, stop the payment going onto the invoice at all and record the excess against the payer, then allocate it to a later invoice or refund it.
Check the client's file in the practice software last. An excess that was not exported often sits there as credit, and that is a different repair with its own page.

Changing when the export runs

Clearing one refusal does nothing about the next one, because the cause is timing rather than data. Zanda's own answer is to export invoices as late as possible, after any card payment and its processing fee have been taken, so the invoice and the payment reach Xero already matching. A practice exporting invoices daily and payments weekly is running the two batches in the order that invites this.

That single change also settles the neighbouring failures, because an invoice exported after the money has finished moving is an invoice nobody needs to edit afterwards. Where the practice deliberately exports drafts for someone to check in Xero, the same care applies to the payments batch that follows, since a payment cannot go onto an invoice that has not been approved.

What Ledger Map does with it

Ledger Map holds one standing map for the practice, approved before anything syncs, and reads the state of the Xero document before it writes. A payment it cannot place becomes a question naming the invoice, the value Xero holds and the value the practice software is sending, rather than a line in an error log that a person has to reverse engineer.

On the money side the rule is the same one every page here states: one balanced document set per deposit, posted to the accounts the map names, leaving one exact match in the bank feed for the bookkeeper to click. The card settlement, the fee and the invoice it belongs to travel together instead of being three separate pieces of manual work. You can see how the map is approved on how it works, or read the rest of the sync failures on the learn hub.

Questions

What does payment amount exceeds the amount outstanding mean in Xero?
It means Xero was handed a payment worth more than the invoice it names still has owing, and refused it. Zanda states the underlying rule as overpayments not being permitted by Xero, meaning payments worth more than the invoice amount. The invoice is untouched by the refusal, and the payment does not land.
Why does a Stripe processing fee cause this error?
The fee is added to the invoice in the practice software after that invoice has already gone to Xero. Taking a card payment with the processing fee setting on adds a fee line, which lifts the practice software total to match the fee inclusive payment. Xero is still holding the older, lower total, so the payment arrives worth more than the invoice.
Can I edit the Xero invoice to add the fee?
Not while a payment or a credit note sits against it. Amounts and quantities are the fields that need the payment removed first, so a fee line cannot be added to a settled invoice, and the write comes back as a status error instead. Zanda's answer for an invoice already across is to export the payment at the value Xero holds and post the fee separately.
How do I stop it happening on the next batch?
Change when the invoices go across. Exporting invoices as late as possible, after any card payment and its processing fee have been taken, means the invoice and the payment reach Xero already agreeing. Zanda gives that as the way to avoid it for future invoices, and it costs nothing to change.
Our payment is in the practice software but Xero does not have it. Same problem?
That is usually a different failure. Cliniko sends a payment only once it has been allocated to an invoice, so an unallocated payment is not seen in Xero, and a payment made from account credit is not accepted by Xero at all. That leaves an open invoice with no error attached, rather than a refused payment.
Where should the excess money sit if it cannot go on the invoice?
The excess sits against the payer rather than against the document. Xero holds an excess as its own object that can be applied to a later invoice or refunded, and the canonical templates hold money taken before a session as a liability until a session uses it. Which of the two applies depends on whether an invoice existed when the money arrived.

Sources

Open questions

No ranking, People also ask set or AI Overview was observed for this query on 3 Sep 2026. The session's search budget was spent and the SERP cache holds no snapshot for this slug, so the answer landscape in the brief is inferred from the snapshot for a neighbouring Xero error string rather than measured here. What this page adds is therefore measured against the vendor help articles read for it, not against a ranked set of results.
Whether Xero raises this same wording when a payment that is already in Xero is exported a second time, leaving nothing outstanding for the second copy to settle. It is a plausible route to the sentence and no source read for this page states it.
Whether a credit note allocated in Xero, which lowers the amount outstanding, produces the same refusal for a payment exported at the original invoice value. Same status: plausible, and unsourced.
Xero's own account of the validation, and of its overpayment and prepayment objects, could not be read on 3 Sep 2026. Every developer.xero.com URL returns a title with no body from here and central.xero.com returned an empty document, so the Xero developer citation is marked unverified and no key fact rests on it.
How a card processing fee charged on to a client should be treated, and whether the fee line is income offset by the expense, is not settled by the canonical templates. They carry a processing fee as an expense of the practice deducted from the settlement and carry no client charged card fee revenue line, so the treatment is left to the practice's BAS agent.
Neither Zanda article carries a last updated date, so the date each was read is the only firm date on either.
No practitioner forum thread could be read in a clinic's own words on 3 Sep 2026, so the first hand description quoted here is the vendor's account of the failure rather than a bookkeeper's.

Troubleshooting Xero exports
Zanda. Retrieved 3 Sep 2026.
primary
Exporting to Xero
Zanda. Retrieved 3 Sep 2026.
primary
Integrate Cliniko with your Xero account
Cliniko. Retrieved 29 Aug 2026.
primary
Allied health by funding source, the canonical template
Ledger Map. Retrieved 3 Sep 2026.
primary
Accounting API, Payments
Xero Developer. Retrieved 3 Sep 2026.
unverified

Review

Last reviewed 3 Sep 2026 by Shane

General information for Australian allied health practices, not tax advice. Confirm a treatment with your BAS agent or accountant before you post it.

Guided onboarding

Run one real month before you go live.

Sign up, connect Zanda and Xero, and replay a month you already closed. The map is reviewed with whoever owns the books, and nothing posts until you approve it.

Start your map

Every practice starts from a template. Nothing posts until the map is approved.