Direct answer

The person who says yes to the work may have no power to say yes to the money.

Approving work and approving payment are two different jobs, and in most companies they belong to two different people. Finding that out at invoice time is the trap. Here is how to ask both questions before you start, the exact wording for the kickoff email and the agreement, and how to route the invoice to the payer with the acceptance attached.

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

Updated October 21, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.

Two jobs, and often two people

Inside almost every client there are two separate jobs. One person judges the work: your day-to-day contact, the marketing lead, the project owner, the person who asked for it and knows what good looks like. A different person releases the money: a founder, a finance lead, a budget holder, someone whose job is paying invoices, not admiring deliverables. In a one-person business the two jobs share a head, and this page is a formality. Everywhere else, they split, and the split is invisible until the worst moment. Your contact accepts the work with real enthusiasm, you invoice, and the invoice lands on the desk of someone who has never seen the work, never heard your name, and has no reason to hurry. Acceptance by someone with no budget feels like progress for weeks. It is not progress. It is a yes from a desk that cannot pay.

Ask both questions before you start

The fix is two questions, asked at kickoff, when they are cheap admin instead of late doubt. Who accepts the finished work? And who releases the payment once it is accepted? Ask them in the kickoff email, so the answers exist in writing, and use these words:

Before we start, two quick things so the end of the job is smooth. Who signs off the finished work as accepted? And who releases the payment once it is accepted? I will send the acceptance to the first person and the invoice to the second, so nothing waits on the wrong desk.

Notice what the wording does. It never accuses anyone of being unable to pay. It frames the split as routing, which is all it is, and it gives your contact an easy way to name the payer without losing face. If the answer is that everything comes to your contact, that is an answer too: write it down. What you cannot afford is reaching the invoice with the payer still a rumour.

The two-line contract note

Once you have the names, two lines in the agreement or the kickoff summary hold them in place for the whole job:

Acceptance: [Name, role] accepts or flags the delivered work, and that acceptance is recorded on the delivery record.
Payment: invoices are issued to [Name, role] on acceptance, payable within [number] days.

Fill in the real names and roles when you write it. The lines do two jobs at once. They fix which desk each document goes to, the acceptance to the approver and the invoice to the payer. And they make acceptance, not the calendar and not your optimism, the event the invoice hangs on. Two lines, agreed while everyone is friendly, replace the most awkward email in freelancing: the one that starts by asking who, exactly, is supposed to pay this.

Run the job so the record names the decider

Paper names are a start. The stronger move is to run delivery so the acceptance itself lands on a record, from the approver, with the decision visible. Then the invoice to the payer carries something better than your summary of a colleague's enthusiasm: the acceptance, naming who decided and when. The two records below are real AER-1 records (IETF Internet-Draft draft-zambo-aer1-24) and show exactly the fields that matter here.

Accepted: a decision is on the record, with a name and a time

Still open: delivered, checked, and waiting on a decision

Read the accepted record the way a payer would. The decision is on the record, the decider is named as the client, the time is stated, and the release hint reads ok_to_release. The pending record shows the other state just as plainly: steps checked, decision still at hold, nobody named yet because nobody has decided. An invoice routed with the first kind of record attached is a short conversation. An invoice routed on the second kind is a request for trust, sent to the one desk in the building you have never spoken to.

The mid-job check

Do not wait for the final invoice to test the routing. At the first milestone, have the approver record acceptance of that stage, and watch what happens. If your approver says the budget is not theirs, you have learned it while the record is still small, and small is when the lesson is cheap. Thank them, get the payer's name, and send the payer the record so far with the acceptance on it, plus one request: confirm, in writing, that they are the payment contact for the rest of the job. If a payer cannot be named at all, that is the most important fact about the job, and the honest options are a deposit, a smaller scope, or a pause, chosen by you, now, instead of an unpaid final invoice chosen for you later.

If you skipped this and the invoice is already stuck

Then do the routing late, and do it with documents, not frustration. Send the payer the acceptance record and the invoice together, and ask your approver to forward it with their acceptance visible, so the payer hears the yes from their own colleague instead of from you. Keep the tone administrative: desks pay paperwork, and your job is to make your invoice the easiest piece of paperwork on that desk. Then fix the front of the process on the next job, with the two questions and the two lines, where this page started.

What this page does not settle

A record shows who accepted the work and when, and its receipt proves the saved result was not changed since it was saved. It does not prove the approver had authority inside their own company, and it cannot make a company pay. Internal authority is the client's housekeeping, and a client can still be slow, disputed, or broke with perfect paperwork. Your protection is asking early, in writing, while the job is small. This page is general information, not legal advice. Zambo never holds your money or the client's.

Frequently asked questions

How do I know the person approving my work can approve the payment too?

Ask, before the job starts, and ask it as two questions, not one. Who accepts the finished work? And who releases the payment once it is accepted? In a one-person business the answer is the same name twice. In any larger client they are often different people: your contact judges the work, and a founder, a finance lead, or a budget holder releases the money. Get both names in writing, in an email or in the agreement, and treat an answer of send everything to me as an answer worth writing down too. You know the approver can pay when the payer has said so, in writing, before the invoice exists, not when the invoice is already waiting.

What exact words do I use at kickoff to ask who pays?

Use this, in the kickoff email: Before we start, two quick things so the end of the job is smooth. Who signs off the finished work as accepted? And who releases the payment once it is accepted? I will send the acceptance to the first person and the invoice to the second, so nothing waits on the wrong desk. It works because it sounds like what it is, admin, asked while admin is cheap. Asked at invoice time, the same question sounds like doubt. Asked at kickoff, it just sounds organised, and the answers become part of the job paperwork.

What two-line note do I put in the agreement?

Two lines are enough. Line one: Acceptance: the named person accepts or flags the delivered work, and that acceptance is recorded on the delivery record. Line two: Payment: invoices are issued to the named payer on acceptance, payable within the agreed number of days. Fill in the real names and roles when you write it: Acceptance: [Name, role]. Payment: invoices to [Name, role]. The lines do two jobs. They fix which desk each document goes to, and they make the acceptance, not the calendar, the event the invoice hangs on.

My approver just told me the budget is not theirs. What do I do?

Treat it as useful news that arrived early, and act while the job is small. Thank them, ask for the payer by name, and send the payer the record so far with a short note: this stage is accepted by your colleague, the invoice for it comes to you, and here is the acceptance attached. Get the payer to confirm, in writing, that they are the payment contact for the rest of the job. If no payer can be named, you have learned the most important fact about the job, and the honest options are a deposit, a smaller scope, or a pause, before more unpaid work goes on the record.

How do I route the invoice with the acceptance attached?

Close each stage on a record the approver decides on, then send the payer that record with the invoice. When the job runs through Zambo, the acceptance sits on the record itself, naming who decided and when, with the decision accepted and ok_to_release, or still pending and hold, so the payer is never asked to trust your say-so about a colleague's approval. For $0.99, run the next job that way: https://zambo.dev/day-pass/ A Day Pass covers 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