Billing, Subscriptions & Revenue
We build and run billing, subscription, and revenue systems for finance teams tired of quarter-end scrambles. Recurring, usage-based, and invoice models bill accurately, pay out on schedule, and match against bank data through automated rules with an exception queue for the edge cases. Reporting sits underneath, so revenue recognition, dunning, and tax filing draw from one source instead of three disconnected exports.
How we help
Three shifts a billing team feels in the first quarter after go-live.
Fewer manual corrections
Today a billing analyst re-keys plan changes and proration by hand, and each typo becomes a credit note next month. We move that logic into the billing engine, so mid-cycle upgrades, downgrades, and refunds calculate once and post to the ledger without a second person checking the math in a spreadsheet.
Cash that arrives on time
Failed card renewals used to sit unnoticed until someone read the payments export. We add retry scheduling, card-updater hooks, and a dunning sequence that emails the customer before the subscription lapses. Recoverable revenue gets recovered, and the finance team sees which accounts still need a phone call.
A close that ends on Friday
Quarter-end meant exporting invoices, matching bank lines by hand, and reconciling three systems past midnight. We connect billing, payments, and the general ledger through automated matching with an exception queue. Most lines clear on their own, and the team spends its time on the handful that genuinely need judgment.
What we deliver
Six parts of the billing stack we design, build, and operate.
Subscription & recurring billing
Plan catalogs, trials, proration, and mid-cycle changes handled in one engine instead of a tangle of custom scripts. Upgrades and downgrades calculate the credit and the next charge correctly, so a customer who switches tiers on the 14th is not billed twice. Annual, monthly, and multi-seat contracts run from the same rules the finance team can read.
Usage & metered billing
Metering that counts events, API calls, or gigabytes and prices them against tiered or volume rates. Today usage data lives in logs and someone builds the invoice in a spreadsheet at month-end. We aggregate the meters, apply the rate card, and post a rated invoice, so the charge matches what the customer consumed and disputes drop.
Invoicing & AR automation
Invoice generation, delivery, and payment matching that replace the manual accounts-receivable chase. Invoices post on schedule, payments match to open items through automated rules, and short-pays or overpayments route to an exception queue. The team stops keying remittance advice by hand and can see aged receivables by customer without rebuilding the report each week.
Revenue recognition (ASC 606)
Recognition schedules built to ASC 606 and IFRS 15, so deferred revenue releases over the contract term instead of landing wherever cash did. Performance obligations, allocation, and contract modifications are modeled in the system rather than tracked in a side spreadsheet. When an auditor asks how a number was recognized, the schedule and the source contract are one click apart.
Dunning & churn recovery
Retry logic, card-updater integration, and staged reminder emails that recover payments before an account churns. A declined renewal used to mean silent lost revenue until someone noticed the drop. We schedule adaptive retries around payday timing, prompt the customer to fix an expired card, and escalate the accounts that need a human to the right person.
Tax & e-invoicing compliance
Tax determination and e-invoicing that keep filings correct as a company sells into more jurisdictions. Rates, thresholds, and place-of-supply rules are calculated at invoice time, not reconstructed at filing. Where a market mandates a government e-invoicing format, we generate and transmit the required document, so compliance is part of the billing run rather than a separate scramble.
Our technology radar
Where we stand today. The Hold ring is the one that matters: these are positions we argue against, including when a client asks for them.
The default unless there is a reason not to.
- Metering as an event stream
- Idempotent invoice generation
- Recognition derived from performance obligations
- Dunning driven by decline reason
- Reconciliation against the ledger, not an export
We use these on new work and watch them closely.
- Real-time tax determination per transaction
- Jurisdictional e-invoicing as a pluggable adapter, given how fast those mandates move
We argue against these.
- Billing logic embedded in application code
- Recognising revenue from invoices
- Fixed-schedule dunning that ignores why the payment failed
- Month-end reconciliation as the first time anyone compares two systems
One engine for recurring, usage, and invoice billing
We consolidate fragmented billing logic into a system your finance team can read, audit, and change without a developer for every rate tweak.
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
Accuracy the ledger trusts
Proration, credits, and tax are calculated once in the billing engine and posted straight to the general ledger. There is no second spreadsheet to reconcile against, so the invoice a customer receives and the number your controller reports come from the same computation and match on the first pass.
Revenue recognition rigor
We model recognition to ASC 606 and IFRS 15 inside the system, not in a workbook a single analyst maintains. Deferred revenue, allocation, and contract changes carry a schedule and an audit trail, so your finance team can answer an auditor without reconstructing how each figure was built.
Recovery of failed payments
Declined renewals are revenue you already earned. We build retry scheduling, card-updater hooks, and dunning sequences that work the payment before the subscription lapses. The accounts that still need a human are surfaced to the right person instead of disappearing into a payments export nobody reads.
We run what we build
The same senior engineers who design the billing system can operate it after launch. Documentation, tests, and audit trails come with the handover. You are not left with an opaque system and a vendor who has moved on when the next tax rule or pricing change arrives.
What our architects hand you
Delivered from Presales and Discovery, yours to keep whatever you decide next.
Book an architecture sessionSystem Design
Target architecture against your systems, with failure domains and the order things get built.
API contracts
Every integration point written before an implementation exists.
Compliance scope assessment
Which systems fall in scope under each option, and what the design removes.
Cloud cost model
What it costs to run at your volume, by component.
Security review
Threat model for the paths that move money or hold personal data.
Migration and cutover plan
Parallel run, reconciliation, gradual shift, and a rollback point at each step.
Questions
Common questions from finance and product teams weighing a billing rebuild.
Can you support usage-based and subscription pricing in one system?
Yes. We model recurring plans, metered usage, and one-off invoices in a single billing engine with shared customer and contract records. A customer can carry a monthly platform fee, per-seat charges, and metered API overage on one invoice. The rate card and proration rules stay in one place, so pricing changes do not mean rebuilding logic in three systems.
How do you handle revenue recognition?
We build recognition schedules to ASC 606 and IFRS 15 directly in the system. Performance obligations, allocation, and contract modifications are modeled so deferred revenue releases over the term rather than following cash. Each recognized figure links back to its source contract and schedule, which gives your finance team and auditors a traceable record instead of a spreadsheet rebuilt every quarter.
Will this integrate with our existing ERP and payment providers?
That is the starting assumption. We map your ERP, general ledger, and payment gateways during discovery and build integration-first, so billing posts to the systems you already run. Automated matching connects payments to open invoices, and an exception queue catches the lines that do not clear. We work with your stack rather than asking you to replace it.
Can we host the billing system ourselves?
Yes. We build for self-hosting where you need it, which matters for teams with data-residency or regulatory constraints on where financial records live. The design accounts for your infrastructure during architecture, and the handover includes documentation and tests. You keep control of the environment, and we can keep operating the system inside it if you want that.
How do you recover failed subscription payments?
We combine retry scheduling, card-updater integration, and staged dunning emails. Retries are timed around common decline causes like insufficient funds near payday, and expired cards trigger a customer prompt before renewal fails. Accounts that stay unpaid escalate to your team with context. The goal is to work recoverable revenue automatically and put a person only on the cases that need one.
Billing, broken down
Each of these goes deeper than this page does: the systems we build, how they are put together, and what we hand over.
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.