ZAMBO.

Direct answer

They say paid. Your bank says nothing. Match the two records.

The invoice chase gets one reply: we paid that last week. Your bank shows no sign of it. Both of you can be telling the truth as you see it, because most of these gaps are boring machinery, not bad faith: a payment sent to old details, a reference that matched nothing, a transfer still moving, a payment applied to a different invoice, or a screenshot of a payment that was scheduled and never actually sent. A small share are a stall wearing the same costume. The method is identical either way, which is why it works: stop trading claims, and match records. Check your side completely, ask for the payment's own details, and line the two up, field by field, until the gap gets a name. Here is the matching, in order.

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

Updated October 31, 2026. First published October 31, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service.

Step 1. Clear your own side completely before you say a word

The first record to audit is yours, because the most common hiding places are on the receiving side. Check every place the money could land: the account on the invoice, any older account you used with this client, the payment processor balance, which is not the same as the bank it pays out to, and any holding or review state the processor shows. Search by amount as well as by name, and search a window wider than the date the client gave, because amounts arrive net of fees, under a company name you do not recognise, or a day or two outside the expected window. Write down what you searched, where, and what you found, even if the finding is nothing. That note is what turns your next message from my bank says no into a checklist the client can act on, and it protects you completely in the rare case the money was sitting somewhere of yours all along.

Step 2. Ask for the payment's own details, not a picture of good intentions

Now ask, in one short message, for the five fields that identify a payment: the date it was sent, the exact amount, the name on the sending account, the destination details it was sent to, and the transaction reference their bank or processor gave it. Explain why in one line: with those five I can match it against my records the same day. Most screenshots prove much less than they look like. A payment-sent screen usually shows that someone scheduled or started a payment inside an app; it may not show the destination, the reference, or whether the payment was later held, returned, or cancelled. A reference number is the field that matters most, because it is the one a bank can trace. A client who genuinely paid can get all five fields from their bank in minutes, and a client who cannot produce any of them has given you information too, of a different kind.

Step 3. Read the two states the job itself can sit in while you match

A payment claim is easier to settle when the work it pays for has one clear state of its own, delivered, checked, accepted, because then the conversation is only about the money's path and never about whether anything is owed. 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 the states a delivery can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, decided 2026-10-16T14:31:51.146Z in that example, fixes the shape of the debt exactly: this work, accepted on this date, at the agreed price, so the payment hunt is a pure matching exercise between the client's transfer and your bank. A pending record, 5 of 5 steps checked and release_hint hold, is checked work still awaiting its decision, and there it is worth recording the acceptance as part of closing the payment question, so a payment that does surface is matched to a finished decision rather than to a job whose state is still being argued about.

Step 4. Work the mismatches in the order they usually occur

With the five fields in hand, the gap is almost always one of five shapes. Still moving: the method's normal clearing time has not passed, so agree the date you will both recheck and stop messaging about it daily. Wrong reference or no reference: the money may have arrived unmatched, so search again by amount and date, and have the client ask their bank to confirm where the reference points. Wrong destination: the payment went to old or mistyped details, and the recall or trace is the sender's bank's job to start, so ask for the trace in writing and note the date it was raised. Different invoice: the payment is real and yours, applied to another bill, so reallocate it in writing and restate the true balance on this invoice. And the fifth shape: no matching payment exists anywhere either side can point to. Then the claim, however sincerely made, has no record under it, and step 5 is the answer.

Step 5. Close it in writing, whichever way the matching lands

If the money surfaces, confirm it the same day in one message: amount, date received, the invoice it settles, and the balance now standing at zero or at the true remainder. That message ends the matter cleanly and is the receipt for the relationship as much as for the money. If nothing surfaces after the checks and the trace window, restate the position factually, without accusing anyone of anything: I have searched these accounts across these dates, your bank's trace shows this, no payment matching these details has arrived, so the invoice stands due in full, payable by this date. Attach your step 1 note. The restraint matters: you may yet be wrong about a processor queue, and a factual letter survives being wrong gracefully, while an accusation of lying does not. What the factual letter also does, quietly, is end the stall if it was one, because a stall can survive a claim but not a matching exercise with dates on it.

Step 6. Set the next job up so paid is a checkable word

Four habits make this conversation nearly impossible next time. One payment route, named in the agreement, so money never has more than one place to hide. The reference is the invoice number, agreed in advance, so every arrival matches itself. Payment details confirmed in writing before the first invoice, and any change of your details announced in writing and confirmed back, which kills the old-details shape and most payment-diversion tricks with it. And a weekly five-minute match of arrivals against open invoices while a job runs, so a gap is found at seven days, when traces are easy, instead of at seventy. None of this needs new software. It needs the payment to travel with the same discipline as the work: named, referenced, and confirmed by both sides.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove a bank transfer happened, cannot trace money between banks, and cannot decide whose account a missing payment sits in. Zambo never holds client funds. The five payment fields, your search note, the bank trace, and the written close are what the conversation stands on. This page is general information, not legal or financial advice; a large sum that vanishes between banks deserves professional help early, not late.

Frequently asked questions

My client says they already paid my invoice but I never received the money. What do I do?

Match records instead of trading claims. First clear your own side completely: every account the money could land in, the processor balance as well as the bank, searched by amount and by name across a wider window than the date given, with a note of what you searched. Then ask the client for the payment's five identifying fields: date sent, exact amount, sending account name, destination details used, and the bank or processor transaction reference. Line them up against your records. Most gaps resolve into a payment still clearing, a wrong or missing reference, money sent to old details (the sender's bank starts the trace), or a real payment applied to a different invoice. If nothing matches anywhere, restate in writing that the invoice stands due, with your search note attached and a date to pay by.

My client sent a screenshot that says payment sent. Is that proof they paid?

It is proof that a payment was started or scheduled inside an app, which is a weaker thing. A screenshot usually cannot show whether the payment completed, was held or returned, what destination it actually went to, or what reference the bank gave it, and those are exactly the fields a missing payment is found by. Thank them for it, treat it as the start of the match rather than the end of one, and ask for the five fields, above all the transaction reference, which their bank can give them and can trace. A client who has genuinely paid is helped by the trace as much as you are, because if the money left their account and never reached yours, only the trace finds out where it went.

How long should I wait before I treat the invoice as simply unpaid?

Work in the method's own time, then in writing. Let the normal clearing window for that payment method pass, recheck both sides on an agreed date, and give the client's bank a reasonable window to run a trace once it is raised. If those steps produce no matching payment, the invoice is unpaid as a matter of record, whatever either side believes, and you say so in the factual closing message: searches done, trace result, no match, balance due in full by a named date. From there it follows the ordinary path for an unpaid invoice. Do not let the question stay open-ended for months; an unclosed matching exercise quietly becomes the payment terms, and they were never the terms either side agreed.

The money went to bank details I stopped using. Whose problem is that?

It depends on whose details they were on the day, and the thread usually answers it. If the client used details from an old invoice after you had announced new details in writing and they had confirmed them, the payment was misdirected by their side and the recall is theirs to chase, with your help identifying it. If you never announced the change, the old details were the standing instruction and you share the repair work: help the trace, check whether the old account still receives, and confirm the correct details in writing for everything after. Either way, get the confirmation habit in place now: details confirmed back by the client before the next payment, so the next change of account is a documented event instead of a gap two people discover weeks later.

How do I make a claim like this easy to settle on the next job?

Tie the money to the same record as the work: one named payment route, the invoice number as the reference, the delivery accepted on a handover the client has already checked, and arrivals matched against open invoices weekly. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, so the amount owed, the work it pays for, and its acceptance state are fixed in one place before any payment question starts, and the only thing left to match is the transfer itself. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, deliver the next job that way and settle the next paid claim by matching, not by arguing: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related