How we built Arrears: four decisions that make invoice follow-up trustworthy

The value of an invoice follow-up system is not the email sending. It is the schema and the payment matching behind it, decided up front so nothing depends on someone remembering to check. Here are the four decisions we made building Arrears, our private reference build.

The problem

Chasing payment is a job someone already has, usually done from memory. The fix is not complicated. It is making the cadence structural, so the business does not lose money to a task nobody has time to do reliably.

Decision 1: escalation as data, not memory

The number of days since the due date decides which template fires: 7, 14, 21, 28, 35 or 42. A Python workflow applies the same rules on every scan. Each invoice gets at most one captured reminder per stage, and a missed scan catches up at the current stage instead of sending a backlog.

Why it matters: the rules live in one place and can be read, tested and changed. Nobody has to remember them.

Decision 2: payment status that updates itself

The payment handler verifies a Stripe-format signature first. Only then does it match the invoice reference, customer, GBP amount and currency before marking the invoice paid. The demo uses signed test fixtures, so no money moves.

Why it matters: an unverified webhook is an open door. Matching on several fields means a payment for the wrong amount or the wrong client is not silently accepted.

Decision 3: polite by design, firmer by schedule

Tone escalates with the day count: a gentle check-in at day 7, a direct request by day 28. It does not turn adversarial before it needs to. The words are decided once, not improvised under pressure.

Decision 4: one ledger, one source of truth

SQLite stores the invoices, the payment events and the captured email outbox. Paid invoices are excluded from later reminder runs. A repeated payment event is recognised as a retry and ignored, so the ledger is not changed twice.

Why it matters: refresh the page and the same state is there. There is one place to look to see what is outstanding.

What the demo shows

• Repeat a run: run the cycle twice on the same demo date and the second run creates no duplicate messages.
• Record a payment: simulate a payment for invoice #1200 and it receives no further reminders.
• Repeat an event: replay the same payment and the handler ignores it.
• Inspect the output: open a captured email to read exactly what would have been sent.

The stack

Python and Flask run the workflow. SQLite holds the ledger. The Stripe Python SDK verifies webhook signatures. A daily timer scans active demo ledgers, and the demo buttons run the same logic on demand.

What it is, and what it is not

Arrears is a private, Alvento-owned reference build, not client work. The public demo uses mock data, captured emails and simulated payments, and we claim no client results. A live rollout needs a payment account set up and an email delivery integration.

Try the demo. If you want the ledger, cadence and matching rules adapted to how you invoice, get in touch.