When Net 30 Becomes Net 90 (And What to Do About It)

You delivered on day 30. The invoice said Net 30. Day 45 came and went, and now the client's finance team says "more like Net 60 from our side" — like that was always the deal.

TL;DR: When net 30 becomes net 90, it almost never happens as one decision — it happens as a string of small delays nobody formally agrees to. Chasing harder doesn't fix it, because the client controls the calendar and you don't. The real fix is tying access to payment status automatically, so a slipping due date has a cost the same day it slips, not three follow-up emails later.

The Due Date That Keeps Moving

You didn't imagine it. The invoice really did say 30 days. Nobody sent you a new contract. And yet here you are, sending a third follow-up to a client who answers in one line: "processing delays on our end, should be resolved soon."

This isn't a misunderstanding. It's a test. The client is finding out, one skipped date at a time, how much slack you'll give before you push back — and every time a due date passes without consequence, you've answered the question for them.

That's not a character flaw on your part. There's also a specific order of operations that stops this before day 45, and most freelancers do it backwards — more on that once you see how the pattern actually works.

Why Net 30 Becomes Net 90 in the First Place

Payment terms aren't really about accounting. They're about who's holding the risk. A client on Net 30 is borrowing 30 days of your work for free. A client who drifts to Net 90 is borrowing three months of it, and once the pattern isn't challenged the first time, there's no natural point where it resets back.

Intuit's 2026 Small Business Late Payments Report puts a number on how common this actually is. 59% of small businesses now have invoices overdue by 30 days or more, up from 47% the year before. The terms themselves predict the outcome: 55% of businesses that invoice on Net-30 terms report overdue invoices, compared with just 26% of businesses that require payment upfront. The average unpaid balance sitting on a small business's books is $17.7K.

There's one more number buried in that report worth sitting with — we'll come back to it once you see what most freelancers try first.

The freelance-media world has a well-documented, extreme version of this pattern. Writers working under Net 90 and Net 120 terms at outlets that later collapsed were left owed tens of thousands of dollars collectively, with one case putting the total above $80,000 across more than 40 writers. Nobody signed up for Net 120. It arrived the way yours might: quietly, then all at once.

Here's what most freelancers try first, and why each one has a ceiling:

• A late-fee or interest clause in the contract. This only works if you're willing to spend more time and goodwill enforcing it than the fee is worth, which on a $4,000 invoice is almost never.

• A stronger contract with a fixed, non-negotiable due date. Better than nothing, but a contract is a promise to sue, not a mechanism. It only pays out if you go to court, and for most freelance invoices the math doesn't work — see is a freelance contract enforceable for the real numbers on legal recovery costs.

• Invoice factoring. A factoring company advances you most of the invoice value now and collects from the client later, for a percentage fee. It solves this month's cash flow. It does nothing about the client doing this again next quarter.

None of these are wrong to have. All of them are missing the same thing.

The Real Problem Isn't the Payment Terms

Here's the reframe: payment terms are just a sentence in a document. What actually decides whether they get honored is what happens the moment they're broken, and for most freelance and agency deliveries, the answer is nothing.

You handed over working code on day 30. From that point, the client has everything they need and you have an invoice. The terms on paper said Net 30, but the real leverage disappeared the second the build went live on their server. The late fee clause, the stern email, the "per my last message" — all of it is you trying to recreate leverage you already gave away for free.

This is structural, not personal. Delivery-before-payment hands the client every card, and a due date is only as real as the consequence attached to missing it. That's the number worth sitting with from the Intuit report, by the way: 12% of businesses report real strain from missed payments under $1,000. This isn't only a six-figure-retainer problem. A slipping due date hurts at every invoice size, because the mechanism that breaks is the same one every time.

If you're also worried about a client walking off with the code itself once it's live, that's the same root cause wearing a different hat — see how to protect your code as a freelancer for the full picture.

How DevAegis Keeps the Terms You Actually Agreed To

DevAegis was built by a developer who lived this exact slide from Net 30 to "we'll get to it." The fix isn't a sharper contract clause. It's making the payment term self-enforcing, so it doesn't depend on anyone's goodwill in month three — and here's the order of operations that actually works: protection goes on before delivery, not after the due date has already slipped once.

You build the project normally; nothing changes about how you write code. Before delivery, you run the DevAegis CLI, which encrypts the compiled build with AES-256-GCM — the decryption key stays with you, not embedded in what you ship. The client deploys on their own infrastructure as usual, and a small DevAegis runtime checks in with the DevAegis API. In good standing, it decrypts in memory and the app boots like any other deployment.

The difference shows up the day a due date passes. You mark the invoice unpaid in your dashboard and flip one toggle. The runtime stops decrypting. The client's build stops booting — they see a payment status screen where their app used to load. Mark it paid, and access restores automatically, no email required on either side.

This has to be disclosed in your contract as a condition of delivery; you're not sneaking anything in. You're licensing software, and the license is conditional on payment, the same way every SaaS subscription on earth already works. Pairing it with a clear kill-switch clause (see kill switch for client projects for how to word it) is what makes it enforceable and defensible if a client ever pushes back.

It also reframes the Net 30-to-90 slide before it starts. When the due date isn't just a line in a contract but the actual condition the client's software runs under, "processing delays" stops being free. You're not chasing the invoice anymore. The invoice is chasing itself.

One thing this doesn't do: recover money you already lost on a project you delivered unprotected, or negotiate with a client on your behalf. It changes what happens on your next delivery, starting the moment you set it up — for a one-off transaction with no ongoing relationship, escrow may actually fit better. Compare a slipping Net 90 against what that float actually costs you, and the monthly cost on devaegis.com/pricing is easy math, not because it's cheap, but because $14,000 unpaid for two extra months is not.

Same Project, Two Ways It Plays Out

This is one delivery, one invoice, watched from day 0 to day 95, twice. Nothing about the client changes between the two versions except what happens after the due date passes.

The One Thing to Do Before Your Next Invoice

Don't try to fix the invoice that's already 60 days overdue with a new tool; that one is a legal and collections problem now, not a protection problem. Start with how to enforce payment as a freelancer if that's where you are today.

Fix the next one instead. Before you deliver your next project, set up DevAegis on it and put a disclosed kill-switch clause in the contract you send alongside it — that's the single action that decides whether next quarter's Net 30 ever gets the chance to become Net 90.

FAQ: Net 30, Net 90, and Getting Paid on Time

Is it legal for a client to unilaterally push Net 30 to Net 90? Not if your contract specifies a fixed due date — a client can't rewrite payment terms on their own just by announcing a delay. In practice, though, "not legal" and "worth fighting over" are different questions; for anything under a few thousand dollars, formal enforcement usually costs more than the invoice itself.

Can I charge a late fee once a client blows past Net 30? Only if your contract already includes a late-fee or interest clause specifying the rate; you can't add one retroactively to an invoice already in dispute. Even with the clause, collecting it still requires the client to cooperate or you to escalate, which is exactly the leverage gap this article is about.

Do state freelance-payment laws cover this? Some do, but narrowly. Laws like New York City's Freelance Isn't Free Act and Illinois's Freelance Worker Protection Act set default payment deadlines and penalties for late payment above a contract-value threshold — useful if you qualify, but they don't apply everywhere and don't help with a client outside their jurisdiction.

Does invoice factoring fix a client who keeps stretching terms? It fixes your cash flow for the invoice you factor, in exchange for a percentage fee taken by the factoring company. It doesn't change the client's behavior on the next invoice, and it doesn't work at all on undelivered or disputed work.

How is a DevAegis kill switch different from just writing a stricter contract? A contract clause is a promise that requires enforcement: court, a lawyer, or at minimum an uncomfortable email exchange. A kill switch is a technical condition instead — the software checks payment status and runs or doesn't, automatically, without anyone needing to escalate anything.