Subscription billing requirements: how to use this checklist before choosing a platform
A finance or product leader choosing between self-hosted Kill Bill, self-hosted Lago or a billing SaaS needs requirements before needing a vendor. This checklist turns that decision into testable subscription billing requirements, each with a stated owner and a verification step you can run against a candidate platform or a partner's proposal. Work through it before any demo, and treat any requirement you cannot test as an open question rather than an assumption.
The rest of the page groups requirements into functional needs (pricing models, metering volume, currencies, tax, payment gateways, dunning, invoice formats and revenue reporting), security and compliance needs (card data scope, access control, change management and logging), integration needs (general ledger, CRM, tax engines and data exports) and operational needs (who runs the platform, upgrades, backups and support hours). Each item states what to decide and how to check it. The same list can be pasted into an RFP so that bidders answer each requirement against the same wording, which makes their responses comparable.
Sign-off matters as much as the list itself. Finance should own pricing, revenue and invoice rules, tax should confirm jurisdictions and reverse charge handling, security should own card data, access and log retention, and engineering should own event volume, hosting and upgrade paths. A requirement that only one of these groups has approved will usually surface as a rework cost after go-live. Ask each group to sign the requirement set before you shortlist vendors, and record any requirement that is still unknown so it becomes a named action with an owner.
Which functional requirements define the billing scope
This table lists the functional requirements that set the scope of a self-hosted billing build, with why each one matters and how to test it before choosing Kill Bill, Lago or a billing SaaS. Use it as a working checklist: run each verification against your own catalog and volumes, and treat any gap as a scoping decision. The main takeaway is that most platform mismatches show up in pricing, proration and invoice output, not in the feature list.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Pricing models (flat, tiered, volume, seat-based, add-ons) | Each model changes how the catalog is modeled and how invoices are calculated. Mixed models in one plan are a common source of rework. | Build a sample catalog with every model you sell, including one plan that combines a seat charge with a usage charge and an add-on. |
| Usage-based and prepaid credit pricing | Metered charges and prepaid balances need event ingestion, rating and credit drawdown rules that finance can explain. | Replay a month of sample usage events through the catalog and reconcile the rated totals against an independent calculation. |
| Metering volume and event rates | Peak event rates and retention set the storage and ingestion design. Estimates from vendors or past projects often differ from real traffic. | Measure your own event volume at peak and at month end, then ask the platform team to size ingestion and storage against those figures. |
| Currencies and multi-entity invoicing | Multi-currency plans need exchange rules, and each legal entity may need its own invoice numbering and bank details. | Create a sample customer in each currency and entity, then check that invoices carry the correct entity, rate source and tax treatment. |
| Proration and trial rules | Mid-term upgrades, downgrades, cancellations and trial conversions drive most credit and revenue disputes. | Run a sample proration for an upgrade, a downgrade and a cancellation on the same day, and compare each result with the agreed commercial rule. |
| Tax handling | Sales tax and VAT depend on customer location, product type and status. Tax logic can sit in the billing catalog or in an external engine. | Submit test customers from each jurisdiction you bill and confirm the calculated tax, rate and exemption on sample invoices with your tax owner. |
| Payment gateways and tokenization | Gateway choice affects card data handling, failed payment flows and refund support. Card data must stay out of your systems wherever possible. | Confirm which gateways have supported plugins, then run a test charge, decline, refund and retry in a sandbox for each gateway. |
| Dunning and retry policy | Retry timing, reminder emails and suspension rules affect revenue recovery and customer experience. Each rule needs an owner. | Write the dunning schedule as a table, then simulate a failed payment sequence and check each reminder, retry and status change. |
| Invoice formats and numbering | Some customers and jurisdictions need specific layouts, gapless numbering or structured e-invoice output. Changes later can require reissuing documents. | Request a sample invoice in each required format from the platform, including a credit note and a corrected invoice, and have finance approve each one. |
| Revenue reporting and general ledger interfaces | Finance needs deferred revenue schedules, credit and refund records and journal entries that match the ledger's account structure. | Export a month of sample transactions and map each line to a ledger account, then confirm totals reconcile to the billing period. |
| Integrations with CRM, ERP and support tools | Customer and contract data often lives in other systems. Unclear ownership of each record causes duplicate or stale customers. | Document the system of record for each customer, plan and subscription field, then test one create, update and cancel event end to end. |
| Operating model and support ownership | Someone must patch, upgrade, back up and respond to incidents. Self-hosting moves that work to your team or to a partner. | Ask the partner to name who handles upgrades, security patches, backups and on-call response, and to state these in the written scope. |
How pricing models and metering volume shape the platform choice
The pricing model decides whether your catalog fits a platform's data model before any feature comparison matters. Flat plans, tiered and volume pricing, seats, add-ons, minimum commitments, prepaid credits and metered usage each map to different objects in a billing engine. Before you shortlist Kill Bill or Lago, or a billing SaaS, write down every plan, add-on and meter, along with its unit of measure, billing period, proration rule and who approves a price change. Then check each item against the candidate's documented catalog model. Where a pricing rule exists only as a spreadsheet convention or a custom script, treat it as a gap to be designed and tested, not a detail to be deferred.
Usage-based and prepaid pricing place the heaviest load on the system. Every billable event must be ingested, deduplicated, rated and attached to the right subscription, and prepaid balances must be decremented in a way that customers and finance can both trust. Estimate event volume per second at peak and per month from your own product telemetry, including retries and batch replays, rather than from a vendor's sample figures. Then confirm with each candidate how its event ingestion and storage scale for that profile, and ask for a load test against your numbers. Note that the event store choice is covered in the usage-based billing topic, so keep this estimate as the input to that decision.
Test the catalog against edge cases before you sign anything. Run a mid-cycle upgrade, a downgrade that takes effect at period end, a cancellation with a partial refund, a change of currency on an existing subscription, a retroactive price correction and a usage event that arrives after its invoice was generated. For each case, record the expected invoice lines, credits and ledger entries, then compare them with the platform's output in a sandbox. Any case that needs manual intervention is a requirement the platform or your implementation partner must handle, and it should appear in the written scope with an owner.
Which security requirements apply to a self-hosted billing system
A self-hosted billing system holds customer, contact and payment-related data, and it can change what customers pay. The six controls below are the ones covered financial institutions and auditors most often ask about, and each one needs evidence from the platform you choose and from the environment you run it in.
Encryption in transit and at rest
The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to encrypt customer information in transit over external networks and at rest. For billing, that covers invoices, contact records, usage events, and any gateway traffic and database backups. Verify TLS on every external endpoint, including webhooks from payment gateways, and confirm that database volumes, object storage for invoice PDFs, and backups are encrypted with keys you manage. Ask the vendor or your partner which components store customer data and where those keys are held.
Multi-factor authentication for all access
The same rule requires multi-factor authentication for any individual accessing any information system. In a billing deployment that includes operators with database access, administrators of the billing application, finance users who approve credits, and engineers with cloud console rights. Confirm that MFA is enforced at the identity provider or the cloud account level, not only in the application, and that service accounts used by integrations are excluded from interactive login and rotated under a documented process.
Role-based access and approval trails
Catalog and price changes are the most sensitive actions in a billing system, because a single edit can alter what thousands of subscriptions are charged. Define roles for catalog editors, price approvers, invoice and credit approvers, and read-only finance users. Confirm whether the platform supports role separation and an approval step for price and credit changes, or whether you must build it in a workflow outside the billing application. Record who requested and who approved each change.
Audit logging of user activity
The FTC rule requires the institution to log the activity of authorized users. For billing, log entries should show logins, catalog edits, manual invoice adjustments, refunds, credits, and changes to payment gateway configuration, each with a user identity, timestamp, and before and after values. Confirm where logs are written, whether they are shipped to a central store that administrators cannot edit, and how long they are retained. Test by making a sample price change and checking that the log entry is complete.
Change management for configuration and code
The rule requires change management procedures. A self-hosted billing system changes through three paths: application upgrades, catalog and configuration changes, and custom plugins or integrations written for gateways and tax engines. Each path needs a tested change in a non-production environment, a recorded approval, and a rollback plan. Ask whether catalog definitions can be exported and versioned in source control, and whether your partner will document the upgrade procedure for each release you adopt.
Vulnerability management and penetration testing
16 CFR 314.4(d)(2) requires annual penetration testing and vulnerability assessments at least every six months unless the institution runs effective continuous monitoring. Schedule assessments against the billing application, its APIs, the hosting platform, and the integrations that carry payment or customer data. Confirm that patch cycles for the billing platform and its database are tracked, and that findings from each test have owners and closure dates. Ask any security testing provider to scope the billing webhooks and admin interfaces explicitly.
What record retention rules mean for invoice and transaction data
Record retention is a requirement to settle before you choose Kill Bill, Lago or a billing SaaS, because it decides how long invoices, credit notes and payment records must stay available and in what form. The clearest published example is SEC Rule 17a-4(b), which requires broker-dealers to preserve for not less than three years records including bills receivable or payable and bank statements, keeping the first two years in an easily accessible place. The rule applies to broker-dealers, not to subscription businesses in general, but it shows the pattern regulators use: a defined minimum period, a defined access expectation, and records that must be retrievable on request.
Most subscription companies are not broker-dealers, so this rule probably does not bind your invoices directly. Your own obligations come from tax law, commercial contracts, lending or payments agreements, and the regulators that supervise your business. Ask counsel and your tax adviser to confirm which retention periods apply to each record type: issued invoices, credit notes, refunds, dunning notices, payment method records, and gateway settlement reports. Also confirm whether any period runs from invoice date, payment date or contract end, because that choice changes how long a self-hosted database must keep historical subscription states.
Turn the answers into requirements the billing platform must meet. Specify how long invoice and payment data stays in the primary database, when it moves to archive, and how an archived invoice is retrieved and shown in the same format. Decide who can alter or delete a record and whether deletion is blocked during a legal hold. Check the eCFR text of 17 CFR 240.17a-4 only as a reference model, and confirm with your implementation partner how backups, purges and data subject erasure requests interact with retention periods.
Which operational requirements decide who runs the platform
This table compares the operational requirements that a self-hosted billing platform must meet, with the verification method for each. Read it before deciding whether your own team, a partner or a billing SaaS should run the platform, because each row becomes an ongoing duty with an owner. The main takeaway is that recovery targets, upgrade testing and failed-payment alerting must be set and proven, not assumed.
| Requirement | What to define | How to verify it | Common gap |
|---|---|---|---|
| Availability and recovery targets | Availability expectations and recovery time and data loss limits set by the business for invoicing, payment retries and customer access | Confirm targets in writing with finance and operations, then test them against the architecture in a staged failover | Targets copied from a vendor brochure rather than set from the cost of a missed billing run |
| Backup and restore testing | Backup scope for the billing database, invoice documents, payment gateway references and configuration, plus retention periods | Run a scheduled restore drill into a separate environment and reconcile restored invoice counts and balances with the source | Backups exist but have never been restored, so the first real test is an outage |
| Upgrade cadence and release testing | Planned upgrade frequency for the billing engine and plugins, and the owner who approves each release | Apply each release to a staging copy of production catalog and plugin configuration, then replay sample invoices and compare totals | Upgrades deferred for long periods, then applied in one large change that alters price or tax calculations |
| Monitoring and alerting for payments and webhooks | Alerts for failed payments, dunning retries, webhook delivery errors, queue backlogs and invoice generation failures, with thresholds agreed by finance | Inject a test failure from a sandbox gateway and confirm the alert reaches the on-call person and creates a ticket | Alerts go to a shared mailbox, so failed renewals are noticed only at month end |
| On-call coverage | Who responds to billing incidents, hours covered, and escalation path to finance and the payment gateway | Run a tabletop exercise on a failed billing run and record response time and decisions | Coverage assumed to be business hours, although renewals and gateway retries run at other times |
| Support model | Internal team, implementation partner, or retainer for fixes, upgrades and plugin support, with named responsibilities | Ask for the written scope of support, response expectations and who holds production credentials | Support scope is undefined, so a gateway plugin defect has no clear owner |
| Environments (dev, staging, production) | Separate environments with masked customer data, the same catalog structure, and controlled promotion of price changes | Confirm that a price change moves from staging to production through the same approval and change record | Staging holds stale catalog data, so tests pass that production later fails |
| Runbook ownership | Named owner for each runbook: failed payment handling, restore, upgrade, gateway credential rotation, and tax plugin updates | Review each runbook after a drill and confirm the owner has performed the steps at least once | Runbooks written by the implementer and never assigned to an internal owner after handover |
The order to settle requirements before a platform is shortlisted
This sequence turns open questions about billing into a written requirements set that a platform can be tested against. Each step builds on the one before, so pricing decisions shape metering, and tax and payment rules are fixed before anyone compares Kill Bill, Lago or a billing SaaS.
Confirm the business and pricing model
Finance and product leadership list every plan type the business sells: flat recurring subscriptions, seat-based tiers, usage-based charges, prepaid credits, one-time fees and hybrids. For each model, write down how a price change, trial, upgrade or downgrade must be billed and prorated. The step is done when every plan has a written rule that someone could check against a sample invoice.
Define metering and expected volume
Engineering and product define which events are billable, where they originate, how often they arrive and how much history must be queryable for invoices and customer usage views. Record peak event rates, retention periods and the latency allowed between usage and invoice. The step closes when the team has a volume estimate and a sample event schema that load testing can use later.
Fix currencies and tax scope
Finance lists every invoicing currency, the rounding and exchange rules used for each, and the jurisdictions where the company must charge sales tax or VAT. Tax counsel or the finance lead confirms whether tax will be calculated inside the billing platform or by an external engine. The step is complete when each jurisdiction and currency pair has a named owner and a documented rule.
Set payment and dunning rules
Payments and risk teams document which payment gateways and payment methods are needed, how card data will be tokenized, and how failed payments are retried, reminded and eventually suspended or cancelled. They also define who approves write-offs and how recovered revenue is recorded. The step is done when the retry schedule and failure states are written out and can be reproduced in a test payment environment.
Specify invoice and revenue reporting outputs
Finance defines the invoice fields, numbering scheme, legal formats and delivery channels, along with the revenue reports and ledger exports the close process needs. Accounting confirms how credit notes, refunds and adjustments must appear. The step closes when a finance reviewer signs off on a sample invoice and a sample journal export, and each required field is matched to a data source.
Assign operating ownership and choose the delivery model
Leadership names the owners for catalog changes, price approvals, gateway configuration, incident response and upgrades, and decides whether the company will self-host, use a billing SaaS or engage a partner to run the platform. Each option is compared against the requirements above and the team's capacity to operate it. The step is done when the ownership list and delivery model are approved and the rewritten requirements are ready to be used as evaluation criteria.
What buyers ask before they commit to a billing platform
How much does a self-hosted subscription billing implementation cost?
No single number applies, because cost follows the written scope. The main cost components are the implementation work (requirements, catalog design, gateway and tax setup, data migration, integrations and testing), the infrastructure you run the platform on, any paid plugins or enterprise support you add, and the internal staff time your finance and engineering teams contribute. Implementation is typically a one-time cost, while hosting, upgrades, monitoring and support recur. Ask for a quote that lists each component separately, names who performs it, and states what is excluded. DeployOpen does not publish a price list. A quote follows from a written scope agreed before work starts.
How long do requirements and implementation take?
The timeline depends on how many pricing models, currencies, tax jurisdictions, payment gateways and source systems are in play, and on how clean the existing subscription data is. Requirements work usually runs before any platform decision is final, because catalog and tax rules shape the design. Ask any partner to show the phases, the decisions that must be closed before each phase starts, and the dependencies on your finance, legal and engineering teams. Most engagements are fixed-scope, so the timeline should appear in the written scope rather than as an estimate in a sales call.
What must our internal team provide before implementation starts?
Your team needs to supply decisions and data, not only access. Finance should own the product catalog, price books, proration rules, credit and refund policy, invoice numbering and the revenue recognition treatment. Tax or accounting should define which jurisdictions and tax rules apply. Engineering should name the systems that send and receive billing data, such as the CRM, the ledger, the data warehouse and the identity provider. Operations should confirm who will receive alerts and who approves changes. A partner can structure this work, but the business owners must sign off on the rules the platform will enforce.
Can a finance team run the requirements checklist without outside help?
A finance team can draft most of the checklist internally, including the pricing models, currencies, invoice formats, dunning policy and reporting needs. Gaps usually appear in the technical areas: how the platform connects to payment gateways, how usage events are ingested and stored, how tax calculations are passed through, and who operates the system after go-live. Those areas need engineering and security input. Many teams complete the business questions internally and then bring in an implementation partner to validate the architecture, test the integrations and turn the answers into a written scope.
How do Kill Bill and Lago compare with a billing SaaS?
Kill Bill is an open source subscription billing and payments platform licensed under Apache-2.0, and Lago is a self-hosted option for usage-based and recurring billing. Both move the infrastructure, data location and customization decisions to your side. A billing SaaS shifts operations to the vendor and typically charges fees that scale with revenue or volume. Compare them on the requirements that matter most to you: catalog complexity, metering volume, data residency, gateway and tax integrations, upgrade effort, and who carries on-call responsibility. Ask each option for its total cost over the period you plan to run it, including your own staff time.
What changes the scope of a billing implementation?
Scope grows with each added pricing model, currency, tax jurisdiction, payment gateway, migration source and downstream integration. Migrating active subscriptions with payment tokens from another platform adds effort, and so does reconciling usage events with invoices or feeding revenue into a general ledger under audit. Compliance expectations also change scope. If card data or regulated financial records are involved, the work needs controls, evidence collection and testing that a simpler setup does not. Ask any partner to list each change that would alter the price or timeline, and to state how a change request is approved in writing.
What should a written quote for billing implementation include?
A useful quote states the scope, deliverables, assumptions, exclusions, acceptance criteria and timeline in one document. It should separate one-time implementation costs from recurring costs such as hosting support, upgrades, monitoring and retainers. It should name the integrations included, the number of gateways and tax jurisdictions covered, the migration volume assumed, and the testing performed before go-live. Ask who does each task, what the client must provide and by when, and how disputes over changes are handled. DeployOpen issues quotes from written scope, so the scoping conversation comes before any fee discussion.
Which questions separate platforms during evaluation
The most useful discriminators are questions a vendor or partner must answer by demonstration, not by slide. Ask each candidate, whether Kill Bill, Lago or a billing SaaS, to show how its catalog expresses your most complex plan without custom code: a tiered and usage-based plan with a committed minimum, a regional price book, a grandfathered legacy price and an add-on that prorates mid-term. Then ask how a price change is proposed, approved and logged, who can publish it, and whether the before and after values appear in the audit trail that your finance team and external auditors will read. A platform that can only change prices through direct database edits fails this test regardless of its feature list.
Next, ask how a failed payment moves through the system. Walk through a card decline with an expired card on file, a soft decline from the gateway, and a customer who updates the payment method during the retry window. Confirm which component schedules retries, where dunning emails are configured, how the subscription state changes at each step, and whether the gateway token is reused or the customer must re-enter card data. Then ask what happens to invoice numbering after a rollback or a voided invoice: is the sequence gapless, is the voided number retained with a reason code, and can the platform reproduce the same numbers after a restore. Finally, ask who applies security patches and dependency updates, on what schedule, and who tests them against your catalog before they reach production. Run the same test script on the same sample data for every candidate. Build the script before the vendor calls, using anonymized subscriptions, two currencies, a tax-exempt customer and a mid-term plan change, and record the expected outputs in advance. Score each platform on the same invoice totals, ledger postings, retry timings and audit entries, and note every step that needed an engineer or a custom script. Partners bidding on the implementation should run the identical script on their own environment so you can compare their effort estimates with observed results. Confirm the platform versions tested, because release numbers change quickly and a demonstration on one version does not prove behavior on the version you will deploy.
How DeployOpen scopes, delivers and supports billing requirements work
DeployOpen turns the answers to this checklist into a written scope for a self-hosted billing platform inside your own cloud accounts or data centers. We plan, implement, customize, integrate, harden, back up, document and support the platform, and we prepare the controls and evidence your compliance assessors will ask for.
How we scope
- We review your pricing models, metering volume, currencies, tax and gateway choices against Kill Bill, Lago or a billing SaaS.
- Scope, deliverables and timelines are agreed in writing before any work starts, so you know exactly what is covered.
- We record who will operate the platform after handover and which responsibilities stay with your team or a retainer.
How we build
- We configure the product catalog, invoice formats, dunning rules and revenue reporting to match the requirements you signed off.
- We integrate payment gateways, tax calculation and general ledger exports, then test invoice and payment flows end to end.
- We run security testing on the billing system and its APIs before go-live, and report findings with remediation steps.
How we hand over
- You receive architecture, configuration, runbook and integration documentation written for your operations and audit teams.
- Access controls, change procedures and logging are documented so your team can show who changed a price or credit and when.
- Handover includes backup and restore procedures, with the operating model confirmed against the responsibilities agreed in scope.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial engagement.
- Upgrades to Kill Bill or Lago releases are planned, tested in a non-production environment and then scheduled with your team.
- When requirements change, such as a new tax rule or currency, we scope the change in writing before altering production billing.
