Billzy
Simple invoice tracking for freelancers / get paid on time.
One thing I keep noticing while building Billzy:
"overdue" is not a useful diagnosis by itself.
It tells you something is wrong.
It does not tell you what to do.
That is why I keep coming back to the 4 buckets from yesterday.
Because each one should trigger a different move:
- setup gap -> fix the missing info before another reminder
- ownership gap -> bring the responsible person into the thread
- priority gap -> change the workflow so delay is not free
- real problem -> stop nudging and resolve the blocker
That feels a lot better than:
"send reminder every X days."
The goal is not to keep the recovery engine busy.
The goal is to pick the smallest move that actually fits the problem.
I think a lot of software fails here.
It gives you a status label and leaves you to invent the recovery logic on your own.
But if the status does not help you choose the next move, it is mostly decoration.
That has become a useful product lens for me with Billzy.
Not just:
"show me what is overdue."
More like:
"show me what kind of problem this is, and what the next move should be."
That feels much closer to the real job.
This applies outside invoices too.
A lot of dashboards describe problems without helping people act on them.
A good operational system should collapse uncertainty into the next move.
Curious how other founders and freelancers think about this:
Which move is hardest to do consistently in your business: fix setup, surface owner, change priority, or resolve the real problem?
When an invoice goes late, most people open email first.
I think that is backwards.
The first 5 minutes should go to diagnosis, not wording.
Before you send anything, ask:
1. Is this a setup gap?
2. Who owns the next action?
3. Was a payment date promised?
4. What changes if that date slips again?
5. Is this actually a real dispute or cash problem?
That one shift changes the whole recovery motion.
Because a bad email is not always the real problem.
Sometimes the contact is wrong.
Sometimes finance was never looped in.
Sometimes the client promised a date and missed it.
Sometimes nothing in your workflow makes delay costly.
Sometimes there is a real issue you have to resolve, not remind away.
That is why I keep thinking overdue recovery should look more like ops triage than email marketing.
The point is not just to say the right thing.
The point is to identify the type of problem fast enough that the next step actually fits.
If you get the diagnosis wrong, even a well-written reminder can still be the wrong move.
That has become a useful product lens for me too.
I do not want Billzy to feel like:
"here is another reminder template."
I want it to feel more like:
"here is the state, the risk, and the next move."
That seems like a much more useful job for software than just scheduling generic nudges.
Curious how other founders and freelancers handle this:
When an invoice goes late, what is the first question you ask yourself before you send anything?
-
1
I ran into the same thing with client work, the first question for me was whether the promised date slipped or I was still chasing the wrong person. I tried a sheet first, then Stripe reminders, and now I'm building ChaseFlow for the awkward middle where reminder 2 needs a different tone, tbh your ops-triage framing is dead on.
The more I work on Billzy, the less I believe in treating every overdue invoice the same way.
I think most of them fall into 4 buckets:
1. Setup gap
Wrong contact, missing PO, unclear terms, no payment path.
2. Ownership gap
Nobody clearly owns approval or the next action.
3. Priority gap
The client probably intends to pay, but nothing in the workflow makes it urgent.
4. Real problem
Cash issue, dispute, missing deliverable, or something genuinely blocking payment.
The reason I keep coming back to this is simple:
each bucket needs a different next step.
Better reminder copy will not fix a missing PO.
More follow-up will not fix missing ownership.
A polite nudge will not fix a priority problem if nothing else changes.
And no amount of perfect wording will solve a real dispute by itself.
That is why I think one of the biggest mistakes in overdue recovery is using the same playbook for completely different problems.
The invoice is late.
But why is it late?
That question matters more than most people think.
Because once you know the bucket, the next move gets clearer:
- setup gap -> fix the missing information
- ownership gap -> surface the responsible person
- priority gap -> change the workflow
- real problem -> resolve the dispute or blockage
That has become a useful lens for me while building Billzy.
I do not just want it to say "this invoice is overdue."
I want it to help answer "what kind of overdue problem is this?"
That feels like a much better foundation for recovery than generic reminders on a timer.
This idea applies outside invoicing too.
A lot of messy operations improve the moment you stop treating every delay like the same problem.
Curious how other founders and freelancers see it:
Which of these 4 buckets causes the most trouble in your business?
-
1
I ran into the ownership gap and promised-date bucket the most, those were the invoices that looked like late payment when the real issue was nobody owned the next click. I tried a spreadsheet first, then Stripe reminders, and now I'm building ChaseFlow around that triage layer, ngl the bucket framing is way more useful than a single aging number.
-
1
Priority gap, easily. Most of my late payments were from clients who genuinely intended to pay, but my invoice just got buried. Two things that made a real difference: sending the invoice the same day work is completed (not end of week) and switching from 30-day to 14-day terms. The shorter window created urgency without upsetting anyone.
The ownership gap is sneaky too. Once I started asking "who actually clicks approve?" at the start of a project and adding that person to the invoice email, chasing dropped a lot.
For UK freelancers, there's also a legal angle worth knowing - you can charge statutory interest on late payments under the Late Payment of Commercial Debts Act. Most clients do not know this. I built a free calculator for it at landolio.com/tools/late-payment-interest-calculator if anyone wants to see what they might be owed.
-
1
This is a really good breakdown.
I think priority gap is probably the most common one too, because intent and urgency are not the same thing. A client can fully intend to pay and still let the invoice slide if nothing in the workflow keeps it visible.
Sending the invoice the same day and shortening terms to 14 days both make a lot of sense to me, because they reduce drift before the recovery process even starts.
And I agree on the ownership point too. "Who actually clicks approve?" is such a better question than discovering halfway through chasing that the real approver was never in the loop.
Also useful callout on the UK late-payment angle. Even if someone never uses it, just knowing that statutory interest exists probably changes how they think about delay.
Curious: which change had the biggest impact for you in practice, same-day invoicing, 14-day terms, or adding the approver early?
-
Most overdue recovery advice is about what to say in the next email.
That matters.
But the more I work on Billzy, the more I think the bigger question is:
what changes when the invoice goes late?
If the answer is "not much," delay is basically free.
The work keeps moving.
The next deliverable still ships.
The client still gets the same access, the same pace, and the same urgency from your side.
So why would payment suddenly become their top priority?
That is the uncomfortable part of late-payment recovery.
A lot of people think about it as a reminder problem.
I think it is often a leverage problem.
Not in a threatening way.
In a design way.
What does your process do after:
- the due date passes
- the client misses a promised date
- the invoice keeps sitting open
Do you keep working as normal?
Do you slow the next phase?
Do you require payment before the next deliverable?
Do you switch to smaller milestones?
If the system never changes, the client learns something too:
payment can slide without changing the workflow.
That is expensive.
This is one of the biggest reasons I think overdue recovery should be treated like operations, not just email copy.
Good systems do not just send reminders.
They change the path when risk changes.
That is how I keep thinking about Billzy now.
Not just:
"when do we send the next message?"
More like:
"what should the workflow do next so late payment stops being a no-cost delay?"
This applies outside invoices too.
In any process, people pay attention when something changes.
If nothing changes, the delay gets absorbed.
Curious how other founders and freelancers handle this:
At what point, if ever, do you change the workflow because payment is late?
The more I work on Billzy, the less I think overdue recovery starts when the invoice becomes late.
A lot of the outcome was decided earlier.
Before the work even started, did you confirm:
- who approves the invoice
- where the invoice should be sent
- what payment terms were agreed
- how payment will be made
- whether a PO or reference number is required
Once an invoice is overdue, people treat it like a collections problem.
But a surprising number of late payments are really setup problems that get discovered too late.
Wrong contact.
Missing PO.
Terms never stated clearly.
No payment link.
No obvious owner.
By the time the invoice is late, you are no longer solving the cheapest version of the problem.
You are fixing process debt in the middle of collections.
That is why I think one of the best things a recovery product can do is not just schedule the next reminder.
It should surface the missing setup step.
What was never confirmed?
What approval path was never made explicit?
What payment instruction is missing?
Because late-payment recovery gets much easier when the payment path was designed early.
This feels like a broader lesson too.
A lot of downstream mess in business is really upstream ambiguity.
If the expectation, owner, and path are unclear at the start, you usually pay for it later in follow-up.
That has changed how I think about Billzy.
Not just:
"help chase overdue invoices."
More like:
"help people close the setup gaps that create overdue invoices in the first place."
Curious what other founders and freelancers think:
What is the one thing you wish was always locked in before you start client work, because it causes the most trouble later?
I think a lot of people escalate off the wrong signal.
They treat the original due date as the moment everything changes.
That matters.
But the more I work on Billzy, the more I think the more useful signal is the first broken promise after the due date.
An invoice being late is annoying.
A promised payment date being missed is information.
Once a client says "we'll pay Friday" and Friday passes, you have learned something new.
Not just that the invoice is still open.
That the current recovery process is not reliable.
That should change the follow-up.
Not necessarily into aggression.
But definitely into a different mode.
You are no longer asking whether the invoice is late.
You already know that.
Now you are asking:
- what blocked the promised date
- who owns fixing it
- what the new committed date is
- what happens if that date slips too
That is a much stronger operating point than just sending another generic reminder.
I keep coming back to this because I think most invoicing tools track the original due date and stop there.
But for actual recovery, the more important date is often the one the client gave you after the invoice went late.
That is the date that tells you whether the conversation is real or just polite delay.
It is also a useful lesson outside invoices.
In business, the moment someone misses their own promised date is often when you stop managing status and start managing risk.
That is how I want Billzy to think.
Not just "this invoice is overdue."
More like:
"this commitment was made, then broken, so the workflow should change."
If I were handling overdue recovery manually, I would want a system that treated missed promises as first-class signals, not just notes buried in an email thread.
Curious how others handle this:
Do you escalate based on the original due date, or based on the first promised payment date that gets missed?
Most people treat late payment like a reminder problem.
Send a better email.
Follow up faster.
Ask for a date.
Those things matter.
But the more I work on Billzy, the more I think a lot of overdue invoices are really an ownership problem.
Nobody clearly owns what happens next.
The invoice was sent by one person.
The work is managed by another.
Approval sits with someone else.
Accounts payable may not even be in the thread.
So you follow up and get something like:
"We're processing it."
"Finance is handling it."
"I'll check internally."
That sounds like movement.
But a lot of the time it just means the next step is floating between people.
That is why I think a useful follow-up should not just ask for status.
It should surface ownership.
Who is approving this?
Who is processing the payment?
Who should be copied to get this closed?
If you do not know who owns the next action, the invoice is still at risk no matter how polite or clear the reminder is.
That has become a product lesson for me too.
The real job is not just sending nudges.
It is making the next owner visible.
Because once there is an owner, the conversation changes.
No owner = vague reassurance.
Named owner = a next step you can actually track.
This feels bigger than invoicing.
A lot of business bottlenecks are not caused by disagreement.
They are caused by missing ownership.
Everyone assumes someone else has it.
So the work sits still while the thread stays active.
If I were writing an overdue follow-up today, I would want it to answer 2 things:
1. What date should I expect payment?
2. Who owns getting this done?
That is a much stronger position than just asking for another update.
Curious how other founders handle this:
When payment gets stuck, do you push for the date first or for the name of the person who owns the next step?
-
1
I had this exact issue with client work, the reminder copy wasnt the blocker, it was never knowing whether AP, the project lead, or the founder actually owned the next move. I tried generic reminder sequences first, then Stripe nudges, and now I'm building ChaseFlow around surfacing that owner before reminder 2, imo the name question changes the whole thread.I had this exact issue with client work, the reminder copy wasnt the blocker, it was never knowing whether AP, the project lead, or the founder actually owned the next move. I tried generic reminder sequences first, then Stripe nudges, and now I'm building ChaseFlow around surfacing that owner before reminder 2, imo the name question changes the whole thread.
-
1
This really resonates. When I was freelancing, I learned this the hard way — chasing late payments by just sending "friendly reminders" almost never worked. The problem was exactly what you describe: nobody on the client's side felt personally responsible for paying me.
What eventually worked for me was asking for the name upfront. Not just "when will this be paid?" but "who specifically is going to process this?" Once you have a name, the dynamic shifts completely. You're no longer emailing into the void. You have someone accountable.
I actually started building this thinking into the invoicing tool I'm working on now. Instead of just tracking "sent" and "paid," we track who the invoice is assigned to on the client side. Small change, but it makes follow-ups way more effective.
To answer your question directly: I push for the name first. Once you have ownership, the date usually follows naturally.
-
1
I agree with this a lot.
"Who specifically is going to process this?" is a much stronger question than most people ask, because it turns a vague thread into an owned step.
That's the part I find most interesting too: once there'ss a name attached, the conversation usually gets more concrete very quickly. The date becomes easier to ask for because there is now someone connected to the outcome.
I also like that you are building this into your tool. Tracking client-side ownership feels small on paper, but operationally it changes a lot because it gives follow-up a target instead of just a status.
That's a big part of how I’m thinking about Billzy too: less “is this paid yet?” and more “what is still unclear, and who owns removing that uncertainty?”
Curious: when you started asking for the name first, did clients usually give it right away, or did that itself require another round of follow-up?
-
1
Good question. Honestly, it was mixed. Smaller clients (solo founders, small agencies) would usually give you a name pretty quickly because there's only 1-2 people who handle payments anyway. The friction was low.
Bigger companies were a different story. The first response was almost always "I'll check" — which is really just a nicer way of saying "I don't know either." But even that response was useful, because it surfaced the real problem: nobody had ownership. That realization alone changed how I framed follow-ups. Instead of "any update?" I'd say "who should I loop in to get this resolved?"
It usually took one extra round. But once I had a name, the next invoice to the same client went smoother because I already knew the path.
-
1
This is a really useful distinction.
"I'll check" is exactly the kind of reply that sounds helpful but usually reveals the real issue: the ownership path is still fuzzy.
That is why I think even a weak reply can still be useful if it exposes the right uncertainty. Once it becomes clear that nobody actually owns the next step, the follow-up gets much more specific.
I also like the point about the next invoice going smoother. That feels important because part of the value is not just recovering the current invoice, but learning the payment path for the client so the same friction does not repeat.
"Who should I loop in to get this resolved?" is a much better line than another generic update request.
Curious: once you had the name, did payment speed improve mainly because follow-up got more direct, or because you could start future invoices with the right person already included?
-
-
-
One of the most dangerous replies to an overdue invoice is:
"We're processing it."
Not because it sounds bad.
Because it sounds good enough to make you stop pushing.
You got a reply.
The silence is broken.
The tension drops.
But most of the time, nothing operationally useful has changed.
You still do not know:
- when the payment will land
- what is blocking it
- who actually owns the next step
That is why I think "we're processing it" is one of the most expensive phrases in receivables.
It gives emotional relief without giving real clarity.
That is a bad trade.
The rule I keep coming back to while building Billzy is simple:
A response is only useful if it creates one of 3 outcomes.
1. The invoice is paid.
2. You get a specific payment date.
3. A real blocker is surfaced.
If the reply does not give you one of those, the loop is still open.
That is where I think a lot of founders lose time.
They treat reassurance like resolution.
So the next message matters.
Not:
"Okay, thanks for the update."
Better:
"Thanks. What date should I expect payment?"
Or:
"If something is blocking it, tell me what it is so we can resolve it."
That is not about being aggressive.
It is about refusing to confuse activity with progress.
This idea applies far beyond invoices.
In sales, hiring, approvals, partnerships, even product work, people say things that lower tension without creating a next step.
"Looking into it."
"Should be soon."
"We'll circle back."
Those replies feel alive.
But they often keep the system just vague enough to stay stuck.
That is a product lesson for me too.
I do not want Billzy to just log replies.
I want it to separate status noise from decision-making.
Because the longer I work on this, the more I think the real cost of overdue recovery is not just late cash.
It is all the fake progress that steals attention while telling you everything is moving.
Curious how other founders handle this:
When someone says "we're processing it," do you accept that as progress or push for a date?
Most overdue follow-up is either too soft or too long.
It turns into another "just checking in" email, or a weird paragraph of apology and context that never gets to the point.
If I wanted an overdue reminder to actually move things forward, I would keep it to 3 sentences.
1. State the invoice and the status.
2. Ask for a specific payment date.
3. Surface the blocker if there is one.
Something like:
"Invoice #1042 for $1,800 is now 8 days overdue.
Can you confirm the payment date?
If something is blocking payment, tell me what it is so we can resolve it."
That is the kind of message I wish more founders, freelancers, and operators sent.
Why?
Because each sentence has a job.
The first removes ambiguity.
The second asks for commitment, not a vague update.
The third gives the client a clean way to raise a real issue instead of disappearing.
Most bad reminders fail for the same reason:
they ask for attention, not a decision.
That is the lens I keep using while building Billzy.
Not just "send a reminder on day X."
More like:
does the message reduce ambiguity and force the next real step?
That idea applies far beyond invoicing.
If your follow-up can be answered with "we're on it" and nothing actually changes, the message was probably too weak.
Direct does not have to mean rude.
Clear does not have to mean cold.
In a lot of businesses, open loops stay open because the message never asks for a concrete outcome.
So for me, this is one of the cheapest communication upgrades a founder can make:
stop asking for updates.
start asking for decisions.
Curious what other founders think:
What would you change in that 3-sentence follow-up to make it better?
Most overdue reminders fail before they do anything useful.
Not because the copy is bad.
Not because the subject line is weak.
Because the question is wrong.
"Just checking in" sounds polite.
"Any update on this?" sounds reasonable.
"Let me know where this stands" sounds professional.
But those reminders usually create the same kind of reply:
"We're processing it."
"Should be paid soon."
"We'll come back to you."
That feels like progress, but it usually is not.
The conversation moved.
The invoice did not.
That clicked for me this week while building Billzy.
I think a lot of people treat overdue follow-up like a tone problem, when it is really a clarity problem.
Once an invoice is already late, the reminder should not just restart the conversation.
It should change the state.
For me, a useful follow-up should push the invoice into one of 3 outcomes:
1. It gets paid now.
2. The client gives a specific payment date.
3. A real blocker gets surfaced.
If the reply does not create one of those outcomes, the reminder probably failed.
That is why I think "just checking in" is one of the weakest lines in business.
It asks for attention, not commitment.
And that creates a weird trap:
you get a reply,
you feel like something happened,
but you are still carrying the same uncertainty as before.
This is where I think a lot of founders, freelancers, and operators stay too soft.
They optimize for sounding nice.
They do not optimize for getting the invoice into a clearer state.
But direct is not the same as aggressive.
I think these questions are much more useful:
"Can you confirm the payment date for this invoice?"
"Will this be settled by Friday?"
"If something is blocking payment, what is it?"
Now the reply can actually help.
You either get paid.
You get a date to track.
Or you get the real reason the invoice is stuck.
That is a much better system than collecting vague reassurance in your inbox.
The interesting part is that this is not just an invoicing lesson.
It shows up everywhere:
- sales follow-up
- hiring follow-up
- partnership follow-up
- customer onboarding
Vague messages create polite replies and open loops.
Specific messages create decisions.
That is the product direction I keep coming back to with Billzy.
Not "send another reminder."
More like:
help people send the kind of follow-up that creates a commitment, exposes a blocker, or forces the next real step.
Curious how other founders handle this:
What is the best line you have used to get a real payment date without sounding aggressive?
1 Comment
I ran into this exact thing with client work, an overdue tag looked useful until I still had to guess whether the next move was nudge, fix missing info, or pull the real owner in. I tried a plain aging view first, then Stripe reminders, and now I'm building ChaseFlow around that next-step decision layer, tbh your 4 buckets are way closer to the real job.