From monthly billing to per-project invoicing

If you finish a project on the 5th and invoice at month-end, you wait 26 days before the payment clock even starts. With net 30 terms, that’s 56 days after delivery before money moves.

That delay isn’t your client’s fault. It’s built into monthly billing — and it compounds across every project you deliver mid-month.

Why monthly billing slows your cash flow

The logic behind monthly invoicing sounds reasonable: batch everything together, send one invoice per client, keep admin clean. The problem is the gap it creates.

On a €3,000 project delivered March 5th:

• Invoice sent: March 31st
• Net 30: payment due April 30th
• Actual receipt: often early May

That’s potentially 56 days between completion and payment. Across 4 active clients with projects delivering throughout the month, you’re carrying a permanent cash lag that never shows up on any invoice — only in your bank balance.

The second problem is reconstruction. Month-end billing means sitting down on the 31st and trying to remember what happened on the 14th. Which revision rounds were billable? Did that kick-off call count? How long was the strategy session for Client B?

If you don’t have a clean record, you bill conservatively. Which means you systematically underbill.

What per-project invoicing actually means

Per-project invoicing means you send the invoice when a defined piece of work is delivered — not when the calendar month ends.

That could be at project kick-off (deposit, typically 30–50%), at a defined milestone (first draft approved, for example), or on final delivery. The trigger is the work, not the date.

It doesn’t require switching to fixed-price work. You can still track hours and bill at your hourly rate. The only change is when the invoice goes out: at delivery, not 31 days later.

For ongoing retainers with continuous, equal-volume work, monthly billing still makes sense. Per-project invoicing is for work with a clear endpoint.

How to switch without disrupting clients

Most freelancers expect pushback. Almost none comes. Per-project invoicing is standard in design, development, consulting, and writing. The trigger — delivery — is more logical to most clients than an arbitrary calendar date.

Start with the next new client. Don’t announce a policy change to existing clients. When you onboard someone new, structure the contract with project-based invoicing from the start. That’s your test case.

Frame it as cleaner admin, not a rate change. To existing clients: “I’m moving to invoicing on delivery rather than month-end — it ties the invoice directly to the work, which is simpler to reference on both sides.” Finance teams often prefer this. An invoice tied to a deliverable is easier to approve than one arriving on the last business day of the month with no clear project anchor.

Keep your payment terms initially. Per-project invoicing and shorter net terms are separate conversations. Change the trigger first. Once clients are comfortable, you can negotiate net 14 instead of net 30 — easier when the invoice references something they just received.

Add a deposit clause for longer projects. If you’re billing at delivery on a 6-week project, you’re still waiting 6 weeks. A 40% deposit at kick-off fixes that and qualifies the client at the same time.

The contract language change

If your contracts specify monthly billing, update the language when you renew or start new engagements.

Replace: “Invoiced monthly on the last business day of each calendar month.” With: “Invoiced upon delivery of each agreed deliverable, as defined in the project scope.”

One sentence. No rate change, no relationship risk.

While you’re updating, check your payment terms too. Net 30 is a default, not a standard. Many freelancers who switch to per-project invoicing move to net 14 — because the invoice arrives when the client just received something, not a month after they half-forgot what the work was.

What you need to track

Per-project invoicing only works cleanly if your billing record is accurate at the moment you deliver. You can’t wait until month-end to reconstruct — the invoice goes out now.

The simplest system: calendar events named by client and project. Every meeting, working session, review round, and kick-off call goes in the calendar with a [Client][Project] prefix. When you deliver, the time record is already there.

This is exactly what Timescanner reads. It pulls from any iCal calendar — Google Calendar, Outlook, iCloud, Notion Calendar, Fastmail — and generates a billing summary by client and project. No timer, no spreadsheet, no memory exercise.

When a project ends on March 5th, you open Timescanner, see the full project breakdown, and send the invoice the same day. The calendar already did the tracking.

When to keep monthly billing

Not everything should switch. Monthly billing makes sense for:

• Ongoing retainers with continuous, roughly equal workload
• Large clients with fixed payment cycles you can’t influence
• High-frequency work where batching genuinely reduces admin overhead

The goal isn’t to switch every invoice — it’s to stop letting month-end add a 28-day lag on work that has a clear delivery point.

If you’re not ready to change the billing model but want to reduce the monthly reconstruction time, making month-end invoicing faster is the other approach. It doesn’t fix the cash flow delay, but it fixes the admin pain.

The bigger lever is the trigger. Invoice on delivery, and the built-in 30-day gap disappears.