Money
Sending, chasing and repeating
An invoice that leaves through the product rather than through somebody's own mail client, three reminders and then silence, and schedules that raise the same document every month.
This closes the gap where everything else worked — issue, print, take a card payment, post to the ledger — and the document still had to leave through somebody's own mail client with the PDF downloaded and the payment link pasted by hand.
Where it goes out from
Over your own mailbox where you have one connected, and over the platform's own transport where you do not. An invoice is correspondence with a client: a reply — *we paid this last week*, *can you re-send it* — has to reach a person rather than a notification address nobody reads.
A lapsed mailbox does not fail the send
It falls through to the platform instead, and the record says which way it went. That matters afterwards, because *did they reply?* depends on knowing where it came from.
A reminder always goes over the platform, never a person's mailbox. Sending an automated chase from whoever happened to raise the invoice puts it in their name and their sent items.
Chasing
| When | What it says |
|---|---|
| Three days before it is due | A note that it is coming up |
| The day after it was due | That it appears to be outstanding |
| A fortnight late | That it is now well overdue |
Three, and then it stops
A schedule that keeps going teaches the recipient to filter the sender, and by ninety days the thing that collects the money is a telephone call. Silence after the third is deliberate.
An invoice nobody chased that is now a month late gets the overdue message rather than all three in one evening — the latest stage that has come round, not the earliest. Being sent a cheerful *due in three days* about something a month old is what makes somebody stop reading them.
Every reminder allows for having crossed with a payment. Chasing somebody who has already paid is the fastest way to lose the goodwill the rest of it is trying to keep.
- A credit note is never chased — that is asking a client to pay you for a refund you owe them.
- Nor is a settled invoice, a draft, or a void.
- A bill is refused outright. Emailing a supplier their own document reads as a demand for money you are not owed.
The payment link is left out where nothing can take the money
Rather than included and landing them on a page with no buttons, which reads as the product being broken at the moment somebody was willing to pay. See getting paid online.
Sending the same invoice every month
A schedule holds a counterparty, some lines, and a rhythm. It raises a draft by default, so somebody opening the product finds it waiting; issuing and sending are opt-in per schedule.
The anchor day is remembered, never carried forward
A monthly schedule on the 31st falls back to the 28th in February and returns to the 31st in March. Stepping from the last date used instead walks 31 → 28 → 28, and the schedule has silently become a February schedule for ever. It is the classic bug in every subscription biller and it is invisible until March.
Each invoice is dated when it was scheduled, not when it was raised. One raised three days late is still January's invoice; dating it the 4th puts it in the wrong period on every report that follows.
Catching up stops at three
A schedule switched off for a year must not raise twelve invoices in one night and mail all of them. Something that far behind needs a person to look at it, and the cap is what makes them.
A schedule with no lines is refused when you save it. It would raise an invoice for nothing every month until somebody noticed, and a zero invoice sent to a client is worse than an absent one.
Collected rather than merely sent
Where the client has left a card on file, a recurring invoice is collected and the document goes out already settled. Where they have not, it goes out as an ordinary invoice to be paid by hand. Nothing configures this: a saved card exists only because the customer agreed to it, so its existence is the instruction. See settlements and saved cards.
What is recorded
Every send is a record — when it went, to whom, and by which route — rather than a flag on the invoice. The questions afterwards are exactly those, and a boolean answers none of them.
- An invoice can be re-sent as often as somebody asks. A client who lost it should not be told no.
- Each reminder stage goes exactly once, however often the daily sweep runs.
- A genuine send failure is retried the next day rather than silently skipped for ever.