ZAMBO.

Direct answer

They paid twice for one job. The extra payment is a problem to close cleanly, not a bonus to keep quiet about.

It happens more often than anyone admits: an invoice gets paid by the client and again by their accounts team, or an automatic payment and a manual one cross in the same week. The money sitting in your account is real, and so is the trap. Spend it or stay silent and you have converted a client's bookkeeping error into your integrity problem, one that surfaces months later in their audit, at the worst possible moment, with your name on it. Handled well, a duplicate payment is the cheapest trust you will ever earn: you found it, you named it, and you closed it against the record of the one job it was paying for. Here is the sequence, in order, including the part most guides skip: proving there was only ever one job and one invoice behind the two payments.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated November 10, 2026. First published November 10, 2026. The records quoted below are real and public, read back from the live service on November 10, 2026.

Step 1. Confirm it is really twice, before you say a word

Three different situations wear the same costume, and each needs a different reply. Two settled payments: two amounts actually landed, on two dates, with two references, both pointing at the same invoice. A pending shadow: one payment landed and a second shows as pending or duplicated in a banking app, which often resolves itself and should never be refunded before it settles. And a bookkeeping ghost: your own software recorded one payment twice, so the duplication lives in your ledger, not in the client's money. Check amounts, dates, and references in the bank itself, not only in your invoicing tool. If the two payments differ in amount, suspect the second is a part payment or a payment for a different invoice before you treat it as a duplicate. Only when two settled payments point at one invoice do you have the situation this page solves.

Step 2. Tell the client first, in writing, the same day

The order of discovery is the whole game. If you tell them, you are the professional who caught it. If their year end audit tells them, you are the supplier who kept it. Send one short message the day you confirm it: the invoice number, the amount, both payment dates, and the sentence that matters, one job, one invoice, paid twice. Attach or link the delivery record for that job, so the client can see the single piece of work both payments were chasing. Then ask one question: refund to the account it came from, or hold as a credit against the next job? Get the answer in writing. Do not let the conversation drift into a phone call resolution nobody can reconstruct later; the fix for a record problem should itself be on the record.

Step 3. Settle it against the one delivery record

What makes the settlement simple is that the work side is not in dispute: one job, delivered once, accepted once. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show what one job's decision layer looks like when it is carried on a record instead of in inboxes:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

Read the accepted record as the shape of your duplicate case: 4 steps, all checked, one client decision, one release state. There is one acceptance for the client to pay against, however many times their systems fired. The pending record shows the opposite state, decision still open, release on hold, which is the state in which no payment should have been made at all, let alone two. Your settlement document is a single line added to that record's story: invoice paid on the first date, duplicate received on the second, duplicate refunded or credited on the third, balance zero. Refund goes to the account the money came from, never to a new account named in a follow up email, because a duplicate payment is exactly the costume payment fraud wears; verify any changed destination by a channel you already trust.

Step 4. Close with a zero balance line, and do not spend the extra meanwhile

Until the refund lands or the credit is applied, treat the duplicate as the client's money sitting in your account, because that is what it is. Do not net it informally against some other amount the client owes you unless the client agrees to that exact netting in writing; quiet offsets are how a clean fix becomes a second dispute. When the money moves back, send the closing line: invoice number, paid once and kept, duplicate returned on this date by this method, balance zero. If the client chose a credit instead, the closing line names the credit amount and the next invoice it will be applied to. File both payment confirmations, the client's choice, and the closing line with the job record. Months later, when their accounts team asks why two payments left for one invoice, either side can answer in one forward.

Step 5. Stop it happening on the next job

Duplicates are usually a process smell: the invoice travelled separately from the work, so two people or two systems could pay it without seeing each other. The prevention is boring and complete. One invoice number per job, printed on the delivery record itself. The payment reference you ask for is that invoice number and nothing else. The moment the first payment lands, send a paid confirmation that carries the job's record link and the words paid in full, which is the message an accounts team searches for before paying again. And deliver through one channel: a job whose delivery, acceptance, and invoice arrive as one linked record gives a second payer nothing plausible to pay twice, because the record already shows the decision and the release state.

What this page cannot settle

This page cannot move money: refunds travel at bank speed through the client's and your banks, and a payment that has not settled cannot be returned early no matter how clear the error is. It is general information, not accounting or tax advice; how a duplicate and its refund are booked, and in which period, depends on your setup and jurisdiction, so a real amount deserves a word with your accountant. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove anything about payments, which live in bank records; what the work record settles is the other half of the argument, that exactly one job and one acceptance stood behind the invoice.

Frequently asked questions

My client paid my invoice twice. What do I do?

Confirm first that both payments actually settled, in the bank, with two dates and two references pointing at one invoice, and rule out a pending shadow and a double entry in your own software. Then tell the client the same day, in writing, before their audit finds it: invoice number, amount, both dates, one job paid twice, and ask whether they want a refund to the account it came from or a credit against the next job, answered in writing. Settle against the delivery record, which shows one job delivered and accepted once, so the second payment has no second delivery behind it and is plainly a credit or a return. Close with a written zero balance line, keep the extra untouched until it moves, and never offset it quietly against other amounts. A duplicate you report makes you look exact. A duplicate their auditor reports makes you look like the finding.

Can I just keep the extra payment if the client never notices?

No, and the reasoning is practical as well as honest. The money was paid against one invoice for one accepted job; there is no second delivery it could be payment for, so keeping it is holding funds you cannot tie to any work, which is exactly the shape that turns a client's bookkeeping error into a dispute about you when it surfaces, and duplicates almost always surface, at a year end close, an audit, or a staff change on their side. The same discovery made by you, on the day you confirm it, costs one short message and earns a reputation for exactness that clients repeat to other clients. The amounts are rarely life changing. The story attached to them, in both directions, is permanent.

Should the duplicate be a refund or a credit against future work?

Ask the client, in writing, and follow their answer; both are clean when they are recorded. A refund suits a finished relationship, a one off job, or a client whose accounts rules forbid holding supplier credits; it returns the money to the account it came from and closes the matter completely. A credit suits an ongoing relationship with a next job already visible; it spares everyone a second payment run, but it must be written down as an amount, tied to the invoice it will be applied to, with the closing line sent when it is used. What neither option allows is the informal middle: keeping the money as a vague balance the client has forgotten, to be argued about when memories differ.

What if the client paid twice and is also disputing part of the work?

Keep the two matters on separate lines, because they settle by different evidence. The duplicate is a payment fact: two settled payments, one invoice, settled from bank records, and it is refunded or credited regardless of how the work conversation goes; holding the extra hostage to the dispute converts their error into your leverage and poisons both talks. The dispute is a work question: it settles against the delivery record, step by step, what was delivered, what was checked, and what state the client's decision is in, accepted or still pending. Answer each in its own message with its own record attached. Clients settle faster with suppliers whose paperwork never mixes money facts with work arguments.

How do I run a job so a duplicate payment has nowhere to hide?

Give every job one record that carries its delivery, its acceptance, and its invoice number together, so a payment always points at a visible state. When the work runs through Zambo, each step lands on the job record with a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, the client accepts on that record, and the acceptance view shows status, decider, date, and release state, which is the page an accounts team checks before paying. New users get 20 calls and 1 wrap-up free every day per agent, and picking up work in another AI is always free. For $0.99, run your next client job on one record from first step to acceptance, invoice it from that record, and send the paid confirmation with the record link, so any second payment is visible as a duplicate the day it lands: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, $19 a month for $ZAMBO holders, or Lifetime at $250 one time.

Related