Direct answer

A new project from a client who still owes you is not new work. It is more of the same risk.

The request feels like a compliment and lands like a loan. Here is how to read the finished job's record first, then answer with one of three doors that all protect the old balance, plus the exact wording that says it as scheduling instead of suspicion.

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

Updated October 20, 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.

The request is flattering. The arithmetic is not.

A client who owes you for finished work and asks for a new project is usually read as good news: they like the work, they are coming back. Look at the balance sheet instead of the compliment. You are being asked to extend more credit to the one client whose payment behavior you have already measured, on a finished job, with the work accepted and the invoice simply unpaid. New work does not dilute that risk. It concentrates it, and it quietly re-prices the old invoice: once project two is under way, project one's payment becomes something the client can dangle, delay, or fold into negotiations about project two's scope and price.

Read the old job's state before you answer

The right answer depends on the state of the finished work, and the state should be a record, not a feeling. Three states matter. Accepted and unpaid: the client checked the work, accepted it, and the money is simply late: this is a credit problem, and the doors below apply in full. Delivered and still pending: the client never decided, so part of the new-project conversation is finishing the old decision first. Disputed: a specific flag exists, and that flag gets resolved on its own merits before anything new is discussed. The two public records below show the two states that matter most:

Accepted: this stage is a settled fact, not a claim

Still open: delivered, checked, and waiting on the client

The accepted record is the closed loop you want every job in before a new one opens: decided by the client, dated, marked ok_to_release. The pending record is a job still holding: complete, checked, and waiting. Stacking a new project on top of a hold does not move the hold. It buries it.

The three doors, and how to offer them

Door one, settle then start: the clean default for accepted-and-unpaid work. The balance clears, the new project starts on your normal terms, and neither job contaminates the other. Door two, deposit plus schedule: the new project starts behind a real deposit, and the old balance goes onto written dates, in the same message that confirms the new start, so there is one agreement covering both. Door three, the paid first stage: a small, self-contained opening stage of the new project, paid in advance, which lets a cash-strapped but genuine client prove the new pattern at low cost to both of you. Notice what every door has in common: the old balance gets a mechanism, not a mention.

If they push back

Pushback sorts clients faster than any reference check. A client who pays on the spot, or picks a door without drama, was a slow payer, not a risk, and the relationship comes out stronger for having terms. A client who treats a settled balance as an insult is telling you the old invoice was never going to be paid voluntarily, and the new project was the leverage they intended to pay it with, later, maybe, partly. Believe that information while it is still cheap. The one response to refuse outright is the consolidated promise: both invoices together when the new work lands. That is the current arrangement, repeated at twice the size.

If you already said yes

It is not too late to restructure. Stop at the next natural stage boundary, deliver that stage as a record, and put the doors in writing before the following stage starts. Keep the finished first job's invoice and record separate from the new project's paperwork; merged files make merged arguments. And from here on, run both jobs stage by stage with acceptance on the record, so the state of every balance is a fact either side can open, not a position either side has to take.

What this page does not settle

Whether to extend credit to any client is a business judgment, and pausing or refusing work can interact with your existing agreement, including notice terms you may owe. This page is general information, not legal or financial advice. A verifiable receipt proves the saved result was not changed since it was saved. An acceptance state shows the client's recorded decision; it does not by itself move money, and Zambo never holds your money or the client's.

Frequently asked questions

A client owes me for finished work and wants a new project started. Should I start?

Not on the old terms, and not on goodwill. Starting project two while project one sits unpaid does one thing reliably: it doubles the amount at risk while halving your leverage, because the old invoice quietly becomes a bargaining chip inside the new job. Answer with one of three doors, all of them fair. Door one: the old balance settles, then the new project starts on normal terms. Door two: the new project starts behind a deposit, with the old balance on a written schedule of dates. Door three, when you want to keep the door open cheaply: a small first stage of the new project, paid in advance, and nothing beyond it until the old balance clears. What is not on the list is starting in full and hoping the two invoices get paid together at the end.

What if the amount they owe me is small?

The size of the balance matters less than the pattern it proves. A small unpaid invoice on finished, accepted work is a complete test of how this client pays, run at a cheap price. Passing that test costs them nothing but the payment itself. If a client will not clear a small, undisputed balance before asking for more work, a larger balance later will not be easier to collect; it will just be larger. Clear the small one first, while clearing it is still easy for both of you.

What do I actually say without burning the relationship?

Say it as scheduling, not as suspicion. The shape that works: name the finished work and its state, name the open balance, then offer the doors with dates. Glad to start the new project. The last one is delivered and accepted, with the balance of this amount still open. Once that clears I can start on this date, or we can start behind a deposit with the balance scheduled across these dates. Which suits you? Every sentence is a fact or an offer. There is no accusation to forgive, and the client who intended to pay all along simply picks a door.

They offered to pay both invoices when the new project finishes. Should I accept?

That offer converts one unpaid job into two, with all of the risk on your side of the table and the payment moment pushed to the day your leverage is lowest, after everything is delivered. Treat it as a no, kindly: consolidated payment at the end is exactly the structure that produced the current problem. If the relationship is worth flexibility, flex on the schedule, not on the sequence: part of the old balance now, the rest on written dates, and the new project's stages paid as they are accepted. Sequence is the protection. Schedule is where kindness lives.

How do I make this call automatic on the next client?

Hold one rule where the record can hold it for you: a new job does not open while the last job's record still shows pending payment on accepted work. When work runs through Zambo, each job closes with the client's own decision on its record, accepted and ok_to_release, or still pending and hold, in plain sight for both sides, so the rule enforces itself without a difficult conversation. For $0.99, run the next job on that footing for a day and see the closed loop for yourself: 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