Billing & subscriptions
Recurring, usage and invoice billing with dunning and audit-ready revenue reporting.
Billing sits between product, finance and the payment providers, and it produces the numbers your auditors read. Oxagile Financial Services builds billing engines that price recurring plans, metered usage and invoices in one rating pass, retry failed renewals on schedules tied to decline reasons, and post revenue under ASC 606 and IFRS 15.
Where it fits
The problem
Plan changes wait on an engineering release. Proration gets settled by hand in a spreadsheet, mid-cycle upgrades produce invoices nobody can explain to a customer, and failed renewals churn quietly. At quarter end the finance team rebuilds deferred revenue from exports, then argues with the billing report about which figure holds.
What we build
A rating engine that handles plans, tiers, metered usage, credits and proration in one pass. A dunning schedule keyed to decline reasons. Invoice and credit note documents with tax determination. Revenue schedules under ASC 606 and IFRS 15, and automated matching against provider payouts with an exception queue behind it.
How we engage
Senior billing engineers work inside your repositories and your cloud, next to the finance people who will own the close. Test suites run against your historical invoices, so a pricing change gets checked before release. At handover the rating rules, migration scripts and exception queue belong to your team.
What we build
Six parts carry a subscription through a price change and into the revenue report.
Rating and pricing
Plans, tiers, seat counts, metered usage, coupons and credits go through one rating pass, so a mid-cycle upgrade produces a line a support agent can explain. Pricing lives in versioned configuration. That takes plan launches out of the release train and off the finance team's spreadsheet.
Dunning and recovery
Renewal failures get grouped by decline reason, then retried on schedules matched to that reason, with card updater lookups and a customer email sequence behind them. Fixed three-day retry loops burn attempts against issuers that would have approved on day seven, and involuntary churn then looks like a product problem.
Proration and plan changes
Upgrades, downgrades, pauses and cancellations compute credits and charges against the exact usage window, with a preview endpoint the product surface calls before a customer confirms. Support teams who recompute proration by hand issue goodwill credits to end the argument, and the books quietly absorb the difference.
Revenue recognition
Contract terms map to performance obligations, and the engine posts deferred and recognized revenue schedules under ASC 606 and IFRS 15, including mid-term modifications. Controllers who rebuild schedules from invoice exports each quarter instead get a report that traces an entry back to the contract and the billing event.
Payout reconciliation
Provider payout files match against invoices and refunds through automated matching rules, and unmatched items land in an exception queue with a named owner. Fees, chargebacks and currency differences post to their own accounts. Month-end stops being a hunt through provider dashboards for one missing settlement.
Invoicing and tax
Invoices, credit notes and receipts render per jurisdiction, with tax determination handled by your tax provider, sequential numbering and archive rules applied. Teams who email PDF invoices out of a shared mailbox lose the trail. Documents get versioned, linked to the billing event, and served through an API.
Billing that survives a pricing change
Rating, dunning, revenue schedules and reconciliation in one system, so a new plan ships without a spreadsheet rebuild at quarter end.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Finance owns the numbers
Controllers and revenue accountants sit in the design sessions, and acceptance tests follow their close checklist. Billing projects that skip that step ship a report finance does not trust, so the parallel spreadsheet survives anyway. Here the close runs off the system, with the exception queue as the escape hatch.
Migration without a billing freeze
Existing subscriptions move in batches, with the old and new engines rating the same period in parallel and a diff report on the invoices. Big-bang cutovers force a freeze and a month of goodwill credits. Parallel rating exposes the mismatches while the old engine is still the source of truth.
Traceable billing events
An invoice line points back to the rating input, the plan version and the usage record that produced it. Auditors who ask how a number arose today trigger a week of manual tracing across exports. A stable event log answers the same question in a query and holds up under sampling.
Questions
Can one system handle usage billing and subscriptions together?
Yes. Metered events, seat counts and flat recurring fees run through one rating pass, so a customer on a base plan with overage receives a single invoice whose lines reconcile. Usage arrives through an ingest API with idempotency keys and late-event handling, because meters do go quiet and then backfill a week of data.
How do you cut failed renewals?
Decline reasons drive the schedule. Insufficient funds retry near payday windows, expired cards trigger a card updater lookup and a customer prompt, hard declines stop attempting. Each cohort gets measured on recovered revenue rather than attempt count, so retry policy gets tuned against evidence instead of a fixed loop somebody picked in 2019.
Will our accountants trust the revenue numbers?
That is a design requirement. Your revenue accountants define the mapping between contract terms and performance obligations, and the schedules follow ASC 606 and IFRS 15. Reports run against the same event log the invoices use. During parallel running they compare system output with their current workbook line by line, and the gaps get closed before cutover.
Do you replace our payment provider or tax engine?
Neither by default. Billing sits above the provider and calls your tax determination service, so the pieces that work keep working. Provider abstraction does make a second processor practical later, and reconciliation covers payouts across providers. If your current provider runs the subscriptions itself, we migrate the schedules and keep the stored tokens.
Part of Billing
Billing systems that charge the right amount and reconcile without a spreadsheet.
Make recurring revenue
predictable.
Involuntary churn, failed renewals, a billing engine that fights you? Tell us what's leaking and we'll fix the pipeline.