Billing App Development

Billing app development builds the subscription management, usage metering, invoice generation, and payment orchestration infrastructure that companies use to charge customers reliably and recognise revenue correctly. The buyers commissioning this work are SaaS companies replacing or extending Stripe Billing with a custom pricing engine, FinTech companies building billing infrastructure for their financial products, and enterprises with pricing models too complex for off-the-shelf billing tools: usage tiers, committed spend with overage, multi-product bundles, or contract-specific pricing.

Building a production billing system is not the same as adding a payment form to an application. Billing infrastructure must handle subscription lifecycle events (upgrades, downgrades, pauses, cancellations, free trial conversions), proration across mid-cycle changes, usage metering at scale, dunning and payment retry logic, tax calculation, and revenue recognition in compliance with ASC 606 or IFRS 15. Getting any of these wrong produces customer disputes, churn, or financial statement errors.

Scrums.com provides dedicated engineering teams to build billing systems to the accuracy, reliability, and compliance standards that SaaS and FinTech companies require.

Billing Platform Architecture

The engineering architecture of a billing platform determines whether it handles pricing model complexity, payment failure recovery, and revenue reporting correctly at scale.

Subscription and Pricing Engine. The pricing engine takes a customer's plan, their usage data, and their contract terms, and produces a billable amount for the period. It must support multiple pricing models simultaneously: flat-rate subscription, per-seat, per-unit usage, tiered (where the rate changes at quantity thresholds), volume (where all units price at the tier of the final quantity), package (a fixed number of units per block), and minimum commitment with overage. Contract-specific pricing adds a further layer: named customers may have rates negotiated outside the standard price book. The engine must resolve the correct rate for each customer and period without hardcoding customer-specific logic.

Usage Metering and Aggregation. Usage-based billing requires collecting usage events from the product (API calls, active users, storage consumed, messages sent), aggregating them by customer and billing period, and feeding the aggregated totals into the pricing engine at invoice generation time. This requires idempotent event ingestion (events delivered more than once must not double-count), event timestamping against the billing period boundary, and the ability to re-aggregate historical periods for invoice corrections. Kafka or equivalent event streaming handles the ingestion volume; the aggregation layer must be deterministic and auditable.

Proration and Mid-Cycle Changes. When a customer upgrades or downgrades mid-cycle, the billing system must calculate what they owe for the remainder of the current period at the new rate and credit them for any unused time at the old rate. The correct proration model (daily vs proportional) and the rounding approach must be consistent and configurable, not ad hoc. Mid-cycle changes must also propagate correctly to scheduled future invoices and to the deferred revenue ledger if revenue recognition is implemented.

Dunning and Payment Recovery. Failed payments are the primary driver of involuntary churn in subscription businesses. A dunning system schedules payment retries on an optimised cadence, sequences different retry strategies by payment method type (card vs bank debit vs bank transfer), sends customer notification emails at the right moments, and escalates to account suspension or cancellation at a configurable threshold. The retry logic must handle partial payment scenarios, expired card updates via Account Updater, and bank return codes that indicate permanent failures versus temporary ones differently.

Types of Billing Platforms We Build

Billing software takes different forms depending on the pricing model, customer type, and whether the billing engine is a standalone service or embedded in a wider financial platform. Scrums.com's mobile app development teams build across the full range of billing platform types in this space.

• Subscription billing engine. Core subscription lifecycle management (plan selection, free trial, trial conversion, upgrade/downgrade, pause, cancel, reactivation) with a configurable pricing engine supporting flat, per-seat, tiered, and volume models. Includes proration, dunning, invoice generation, and revenue recognition.
• Usage-based billing platform. Event ingestion and metering layer that aggregates usage data by customer and billing period, feeds totals into the pricing engine, and generates invoices based on actual consumption. Supports committed-use minimums with overage and metered add-ons alongside a flat subscription.
• B2B invoice and accounts receivable automation. Invoice generation for contract-based customers with configurable payment terms (net-30, net-60), automated payment reminder sequences, partial payment recording, and accounts receivable ageing dashboards. Includes PEPPOL/e-invoicing integration for customers with electronic invoicing mandates.
• Embedded billing for platforms. Billing capabilities exposed via API for multi-tenant SaaS platforms where each tenant has their own subscribers. Requires tenant-scoped billing configuration, billing analytics per tenant, and consolidated platform-level reporting.
• Revenue recognition platform. ASC 606/IFRS 15 revenue recognition engine that separates contract recognition from cash collection, tracking deferred revenue balances, recognising subscription revenue over the service period, handling contract modifications, and producing the disclosure schedules required for financial reporting.

Our product development model structures teams around your pricing model complexity and compliance requirements. Start a conversation about your billing platform build.

Technology Stack

• Pricing and subscription engine. Java or Kotlin Spring Boot service with a configurable pricing rule model. Price book, plan definitions, and customer-specific rate overrides are data, not code, and are updatable without deployment. Plan change events are published to downstream services (revenue recognition, entitlements, notifications) via event bus.
• Usage metering. Kafka for idempotent event ingestion at scale. ClickHouse or BigQuery for period aggregation queries. Usage events are immutable and stored for re-aggregation and billing dispute resolution across any historical period.
• Payment orchestration. Stripe Billing or Adyen for card and bank debit processing. GoCardless for direct debit (UK BACS DD, SEPA DD, ACH). Stripe Account Updater or Mastercard MATCH for card refresh. Payment retry scheduler backed by a PostgreSQL job queue with configurable retry cadence per payment method type.
• Invoice and document generation. iText or Apache FOP for PDF invoice rendering against a configurable template. Multi-currency, multi-locale, multi-VAT number. PEPPOL Access Point integration for e-invoicing mandates. Invoice records are immutable; adjustments are credit notes, not edits.
• Tax calculation. Avalara AvaTax or TaxJar for US sales tax nexus management and EU VAT calculation. Tax determination called at invoice generation time with the customer billing address and product tax category. Tax amounts recorded at the line level on each invoice.
• Revenue recognition. Append-only deferred revenue ledger in PostgreSQL. Each subscription creates a deferred revenue schedule; revenue is recognised daily over the service period. Contract modifications trigger new schedule calculation (cumulative catch-up or prospective per the ASC 606 modification type).
• Analytics. MRR/ARR metrics, churn, expansion, contraction, and reactivation revenue waterfall reports built on BigQuery or Redshift from the billing event stream.

Regulatory Compliance

• PCI-DSS. Card data never touches the billing service. Card collection happens via Stripe Elements or Adyen Drop-in (iframes hosted by the payment processor), which returns a token. The billing service stores only the token, last four digits, and expiry date. PCI scope is minimised by design from the first architecture review.
• ASC 606/IFRS 15. Revenue recognition for subscription billing requires separating the performance obligation (access to the software service over the subscription period) from cash collection. Annual prepayments create deferred revenue that must be recognised ratably. Contract modifications, including mid-year plan changes and early terminations with credit, require determination of whether they constitute a new contract (prospective) or modification of an existing one (cumulative catch-up). The billing system must generate the disclosure schedules required for external audit.
• EU VAT and OSS. Digital services sold to EU consumers require VAT collection at the customer's member state rate. The EU One Stop Shop (OSS) scheme allows a single quarterly return rather than registrations in each member state. VAT determination requires the customer's billing country and B2B/B2C classification via validated VAT number for B2B reverse charge. EU ViDA requirements for real-time digital reporting from 2030 mean e-invoicing infrastructure should be planned now.
• UK MTD for VAT. VAT-registered businesses above the threshold must submit VAT returns via Making Tax Digital-compatible software using HMRC's API. Billing platforms serving UK businesses need MTD-compliant VAT calculation and direct API submission capability.
• GDPR. Billing data includes financial transaction records, payment method metadata, and invoice history. Retention periods differ by jurisdiction (UK HMRC: 6 years; EU: varies by member state). GDPR deletion requests must be balanced against legal retention obligations. Enrichment data can be deleted while statutory transaction records are preserved.

Why Companies Work With Scrums.com

Billing errors are not invisible. A proration calculation that gives customers a larger credit than they are owed creates revenue leakage at scale. A dunning sequence that retries failed payments on the wrong cadence increases involuntary churn. Tax miscalculation in a jurisdiction with audit-trail requirements creates compliance exposure. Revenue recognition that does not correctly track deferred revenue produces financial statements that do not reflect economic reality. These are the failure modes that emerge from treating billing as a simple payments problem rather than a financial engineering discipline.

Scrums.com has built production financial infrastructure where data accuracy, payment reliability, and compliance are non-negotiable, including national-scale payment compliance infrastructure and FinTech platforms requiring high availability under production load. We apply that discipline to billing platform engagements from the first architecture review.

Our dedicated team model means your engineers are not shared across other client projects. Teams are structured around your pricing model complexity, payment methods, and compliance requirements. Usage-based pricing scales with team size, with no retainers or long-term lock-in. Scrums.com teams are ready to deploy within 21 days. Tell us what you are building.

Billing App Development: Common Questions

How do you handle usage-based billing at scale?

Usage-based billing requires an event ingestion layer that receives usage events idempotently, an aggregation layer that groups events by customer and billing period, and a pricing engine that applies the correct rate tier to the aggregated totals. Kafka handles event ingestion; ClickHouse or BigQuery handles period aggregation. Events are stored immutably so any billing period can be re-aggregated for corrections or disputes. The key architectural decision is separating the metering layer (raw events) from the rating layer (applying prices) so that pricing changes do not require re-ingestion of historical events.

How do you build proration for mid-cycle upgrades and downgrades?

Proration requires calculating the unused value of the current plan for the remaining days in the billing period, and the cost of the new plan for the same period, then applying one as a credit and the other as a charge. The proration model (daily vs proportional) and the rounding approach must be consistent and configurable, applied uniformly to avoid cumulative errors across large customer volumes. Mid-cycle changes must also propagate to the scheduled future invoice and, if revenue recognition is implemented, to the deferred revenue schedule.

How do you approach dunning and payment recovery?

Effective dunning requires a retry cadence calibrated by payment method type. Card retries on day 1, 3, 7, and 14 work differently from BACS direct debit returns, which have different failure types and processing windows. The retry scheduler must handle partial payment scenarios, card updates via Account Updater, and permanent failure codes (account closed) versus temporary ones (insufficient funds) differently. The suspension and cancellation threshold is configurable per business model, as a high-ACV enterprise customer warrants a longer dunning window than a low-ACV SME subscription.

What is required for ASC 606 compliance in a billing platform?

ASC 606 requires tracking the performance obligation separately from cash collection. For subscription billing, this means creating a deferred revenue schedule when an invoice is paid, recognising revenue daily over the subscription period rather than at point of collection. When a customer upgrades, downgrades, or cancels mid-period, the system must determine whether the modification is a new contract (prospective recognition) or a change to an existing one (cumulative catch-up from the modification date). The billing system must generate deferred revenue roll-forward disclosure schedules required for external audit.

What is the engagement model?

Engagements begin with a discovery phase covering your pricing model, payment methods, tax requirements, and compliance obligations before any code is written. This produces an architecture document and a phased delivery plan. Development proceeds with a dedicated team typically including a senior backend engineer, a payments specialist, and a QA engineer. Teams are ready to deploy within 21 days of engagement start.