When your pricing model depends on consumption, cash doesn’t arrive in a neat monthly transfer. It drips in micro-payments. That sounds elegant—until “billing day” turns into a call center for complaints: disputed charges, “why this amount?”, failed payments, cross-border fees, messy refunds, credit notes that don’t match invoices. What follows is the framework we used to rebuild collections for a European SaaS platform billing by usage across the US, UK, and EU. Conversions improved, refunds became predictable, and month-end close turned boring—and boring is a compliment.
The pain at the start
The platform logged usage snapshots into ClickHouse and aggregated them daily. A customer was considered “paid” if a card transaction cleared on a single EU merchant ID. Refunds ran through the same pipe. Predictable surprises appeared every weekend: UK debit cards falling on cross-border attempts, US issuers soft-declining variable amounts, enterprise clients demanding invoices and bank details, while support handled “where is my payment?” and “why did you charge this much?”. Finance closed the month with CSVs, spreadsheets, and prayers.
Adding “another payment method” wasn’t the answer. The answer was an operational model where meter → accrual → document → collection → refund/credit live as one event-driven chain, not as five disconnected teams.
The operating idea in a paragraph
We split customers into two economic regimes and built rails accordingly. SMBs and startups paid into a prepaid wallet in their local currency (EUR/GBP/USD) with small auto-top-ups. Enterprises ran postpaid, receiving weekly invoices, paying via SEPA Direct Debit/ACH pulls with a backup card on file. Collections used local rails: SEPA in the eurozone, Faster Payments in the UK, ACH in the US. Cards became the fallback, not the main event. Refunds and credit notes flowed back through the same rails in the same currency. Reporting lived in EUR; FX only happened in structured sweeps, never at random. The key variable was events, not files: every step wrote to the ledger, and the ERP listened to events, not emails.
From usage to invoice: ending disputes
We stopped improvising billing logic and standardized it at the data level. Each usage event carried three anchors: who (tenant/project/user), what (metric/units/tariff), and when (UTC window). Billing didn’t do “daily snapshots” anymore but fixed windows—say hourly—applied tariff rules from the price list active at that moment, and wrote an accrual in the ledger in the tariff’s currency.
Dispute on price? The ledger shows which units, which rate. Dispute on timing? The window shows timestamps with timezone-neutral logic. Once the accrual was logged, a document was born: for prepaid customers, a wallet top-up once the threshold was hit; for postpaid, an invoice with metric breakdowns.
The effect was immediate: when customers saw the same fields in invoices as in their usage reports, complaints dropped. Transparency saves money—it’s not a slogan.
Prepaid wallets instead of “long” card roulette
For customers with spiky spend, prepaid wallets brought stability. Balances lived in customer currency. When the balance fell below threshold, billing triggered a small top-up, ordered by preference: SEPA Instant/FPS/ACH first, card second. In practice, EU/UK clients preferred A2A rails—funds cleared in minutes, fees were stable, refunds equally local. The tokenized card remained as fallback for nights and Fridays after cut-off. Refunds for overcharges came as credit notes plus immediate outbound transfers on the same rail, not as negative usage entries. Balances stayed clean, accounting reconciled without drama.
Postpaid without Friday roulette
Enterprises received a predictable rhythm: weekly invoices in their own currency; SEPA Direct Debit (Core or B2B depending on profile) in Europe; ACH WEB/CCD in the US. The backup card was only for emergencies. Pre-notifications went out separately—not just a rule but the antidote to “we didn’t know”. Debit attempts aligned with banking windows, not midnight experiments. Refunds and partial credits followed the same method as the original payment, with support quoting a local-time value date instead of “whenever it clears.”
Refunds and credit notes: timing beats speed
We stopped promising “instant refunds.” Instead, we promised what we could always keep: approvals today, credited to the local bank on the next business day. Cards followed scheme rules, but we triggered them immediately and sent advice. Before releasing funds, the ledger revoked entitlements, attached a credit note to the original invoice with identical pricing and tax context, then executed the outbound payment. Agents no longer guessed; they cited “revoked at X, memo Y, value date Z.”
Why we ditched card-only—and what the numbers said
Cards still matter for onboarding and as backup. But the heavy lifting belongs to banking rails: higher approvals, cheaper unit economics, predictable refunds. Once SEPA Instant, FPS, and ACH were in play—with tokenized cards as fallback—renewal approval rates rose, and cost per successful charge (including retries and disputes) fell by several basis points. In the US, the Friday spike of “soft declines” on variable charges disappeared—because we stopped hitting Friday and shifted many clients to ACH with pre-verified accounts.
Price, currency, FX: who sees what
Customers saw their price in their currency. Finance saw EUR/USD/GBP pools with ceilings and thresholds. Sweeps into EUR followed calendars and caps; each conversion logged achieved vs benchmark rates. No per-transaction FX, no DCC, no surprises. Reported revenue came from events, not from marketing optimism.
Taxation without heroics
Every SKU carried a flag: ESS/service/product/package/webinar. For B2C, we stored two consistent location proofs (billing country, BIN country, IP/delivery). For B2B in the EU, VAT IDs were validated and reverse-charged on invoices; for B2C, the buyer’s country VAT applied and OSS when needed. Credit notes mirrored the original tax context; no manual edits, no “creative” reporting.
Risk and “boring” controls
First refund only to the original source. First payout only to a name matching the profile. Bank detail changes required out-of-band confirmation and cooling-off. New accounts carried refund and auto-top-up caps that warmed up with good behavior. For Direct Debits, accounts were validated before the first pull, to avoid R01/R03 surprises later.
Month-end in two days, not eight
Because there were no “files,” only events: usage accrual, invoice issued, funds received, refund executed, chargeback opened/closed, FX swept. The ERP consumed events, not CSVs. For bank transfers, each account used a virtual IBAN/reference; >95% matched automatically, with the rest flowing into a short, scripted exceptions lane.
Dashboards that kept the system honest
Not a thousand graphs, just five that mattered: approvals by method and corridor; cost per successful charge; time from usage → invoice → cash in hours; share of credit notes leaking into next reporting period; FX achieved vs benchmark. With those five visible weekly, discipline held.
Three billing cycles later
SMBs stopped burning on variable card declines—the wallet plus local rails gave predictability. Enterprises stopped fighting finance—invoice, debit, pre-notification, and refund all ran on one visible track. Tickets asking “where is my refund?” collapsed, because we could give a date and hit it. Auto-recon passed 95%, manual work stayed only for true anomalies. And the quietest change of all: month-end close. Nobody carried CSVs home at night.
What to do first if you start tomorrow
Don’t spread thin. First—usage → accrual → document as one function. No class, no sale. Then add SEPA/FPS/ACH and virtual references, with cards as fallback. Then wallets and Direct Debit. Only later, tweak retries and marketing nudges. The more boring the calendar and rules, the more resilient the money.