Why billing consolidation after an acquisition is a controlled migration, not a data copy
The acquired product typically runs its own subscriptions, payment gateway accounts, tax settings and invoice number series, while the group needs one revenue picture for its financial statements. Consolidation is therefore a controlled migration with cutover, reconciliation and evidence at every step, not a copy of tables from one database to another. The timing is set by the SEC staff position on newly acquired businesses. Management may exclude the acquired business from its assessment of internal control over financial reporting, but the exclusion cannot run beyond one year from the acquisition date or cover more than one annual report, and the excluded business and its significance must be disclosed (SEC ICFR FAQ). Confirm the acquisition date, the first annual report affected and the period in which the acquired billing data must be inside the group's controls before you fix a cutover date.
On platforms, the short answer is that Kill Bill or Lago is the likely target billing engine, because both are open source subscription billing systems that can hold the group's catalog and subscription lifecycle after the move. The ERP that receives the revenue entries and the payment gateways that hold customer payment methods should follow the group's existing stack, not the acquired company's. Before you commit, confirm which general ledger the group closes on, which gateways already hold tokens for the acquired customers, and whether the target billing engine can import subscriptions with their existing billing dates, prices and invoice series. Those three answers decide most of the migration design that follows.
Treat the migration as an in-scope IT change: the catalog mapping, the cutover run and the reconciliation reports need named owners, change records and retained evidence, because auditors will test the new system as part of the group's IT general controls. The SEC guidance on internal control names program changes and access to programs and data as the control areas to evaluate where they affect financial reporting (SEC Release 33-8810). Plan for a period where the old and new systems both show the acquired revenue, and agree in writing which system is the source of record for each month.
Which regulatory and control requirements shape the migration
This table maps the rules most likely to constrain moving an acquired product's subscriptions onto the group's billing platform, and what each one means for the build. Read each row as a question to settle before the catalog freeze and cutover plan are fixed. The main takeaway is that the timing of the migration, not only its technical design, is often set by these obligations.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| SEC ICFR exclusion window (SEC staff FAQ, Question 3) | If the group is an SEC registrant, the acquired billing flow may be excluded from management's internal control assessment for a limited period, but not beyond one year from the acquisition date or more than one annual report. Plan the migration so the acquired system is either brought into scope within that window or its exclusion is disclosed. | Acquisition date, significance analysis of the acquired business, written exclusion decision and disclosure draft |
| IT general control areas (SEC Release 33-8810) | Program changes, access to programs and data, program development and computer operations are the control areas to evaluate where they affect financial reporting. Freeze catalog and price changes during cutover, and restrict who can alter tax, plan or proration logic in both the legacy and target systems. | Change tickets for catalog edits, access reviews for billing admins, list of IT general controls tied to revenue |
| Form 8-K Item 1.05 and third-party oversight disclosure (17 CFR 229.106) | A migration can coincide with a security incident or a vendor change. Name the incident owner and the materiality assessment path before cutover, and track the billing platform, gateways and hosting providers as third-party services the annual report must describe. | Incident runbook covering the migration window, vendor inventory with oversight activities per provider |
| FTC Safeguards Rule (16 CFR 314.4), where covered | For non-bank financial institutions covered by the rule, the migration must keep encryption in transit and at rest, enforce multi-factor authentication for anyone accessing the billing system, follow documented change management, and log authorized user activity. Confirm applicability with counsel before assuming it applies. | Encryption configuration for migration pipelines, MFA enrollment records, change management procedure, activity logs retained across both systems |
| PCI DSS scope for migrated card data | Migrating payment method tokens between gateways may move the cardholder data environment. Whether a card number ever touches the migration tooling determines the scope. Confirm with the acquiring bank or payment brands which entity must validate and on which template, since they, not the PCI SSC, decide. | Data flow diagram for token transfer, written scope statement, validation documentation on the applicable PCI SSC template |
| GDPR Article 28 instructions for acquired customer data | Once the acquirer controls acquired customer records, the processing terms must be documented instructions. Where the acquirer's staff or a non-EEA group entity can access EU records during migration, a transfer mechanism is needed, as EDPB Guidelines 05/2021 treat remote access from a third country as a transfer. Update records of processing to reflect the new controller and security measures. | Updated data processing agreement or instructions, records of processing entries, transfer assessment for any remote access |
| DORA Article 28 register and exit plan (where the target is an EU financial entity) | The register of ICT service arrangements must reflect the target's billing provider and hosting before and after migration. For services supporting critical or important functions, a tested exit strategy and transition plan are required, which the migration plan can serve as evidence for if it is documented and tested. | Updated register entries at entity and group level, transition plan with tested rollback, dependency map for billing services |
What data and systems move in an acquisition billing migration
The migration is only as complete as the object inventory behind it, so start by mapping every billing object the acquired product depends on. That means the product catalog and price plans (including grandfathered prices that customers still pay), active subscriptions with their billing anchor dates and current mid-term periods, invoices and credit notes with their numbering series, payment method tokens bound to the acquired gateway, dunning state for overdue accounts, tax configuration per jurisdiction, and the link from each invoice to the general ledger accounts it posts to. Confirm with the acquired team which of these live in the billing database, which sit in the gateway or a tax plugin, and which exist only in spreadsheets or finance exports. Objects held outside the billing system are the ones most often missed.
Acquired data may also sit under a different legal regime from the acquirer's own records. If the target stores EU customer or invoice data, moving it to the group's platform in another country can count as a transfer or a change of processor, so confirm the data location and the controller and processor roles with counsel before any extract leaves the source environment. Legacy records may also carry retention obligations. Where the acquired business is a broker-dealer, SEC Rule 17a-4(b) requires bills receivable or payable, bank statements and originals of business communications to be preserved for not less than three years, the first two in an easily accessible place. Decide whether migrated invoices are the retained originals or whether the source system must be kept readable, and document that decision with the records owner.
Choosing between big-bang cutover, staged migration and parallel run
When the acquired product has a small number of active subscriptions, a single cutover window is often the simplest path. All subscriptions, plans, price points and payment method references move in one planned event, the old billing system is set to read-only, and finance confirms totals before the new system bills again. The operational work is concentrated into a short, well-rehearsed window, and there are fewer moving parts to reconcile afterward. The trade-off is that a failed cutover affects every customer at once, so the rollback decision must be made before the window opens.
- Rollback path: Define the point of no return in advance, usually the first invoice run on the new platform, and keep the old system in a read-only but restorable state until finance signs off.
- Reconciliation load: Expect a single, complete comparison of subscription counts, MRR and open invoices between the two systems, with exceptions worked before go-live.
- Freeze requirements: Plan a short catalog and price change freeze so the migrated plans match what customers were quoted.
- Invoice numbering: Confirm how the next invoice number continues from the last number issued by the old system, and whether the sequence must be unbroken for the legal entity.
- Rehearsal: Run the full cutover at least once against a recent copy of production data.
Before committing to this approach, ask the implementation partner to show the rehearsal results and the exact rollback steps with named owners.
When a large base of subscriptions is mid-term, a single cutover is usually too risky because every customer's billing anchor date, proration state and renewal terms must carry over correctly. A staged migration moves cohorts of subscriptions in batches, often grouped by plan, region, billing day or entity, and each batch keeps its existing billing dates. The team learns from early batches and adjusts mapping rules before the larger cohorts move. The cost is a longer period in which two systems hold live subscriptions, so each cohort needs clear ownership of which system bills it.
- Billing anchor preservation: Map each subscription's next billing date and current period boundaries explicitly, so no customer is billed early, late or twice.
- Proration and credits: Migrate unused balances, credits and pending changes as explicit opening balances rather than recalculating them.
- Rollback path: Roll back per cohort by moving subscriptions back to the source system, which requires that the source keeps its billing configuration until the last cohort is closed.
- Reconciliation load: Reconcile each cohort against source invoices for its first full billing cycle, which keeps the work spread over time but multiplies the number of checks.
- Ownership register: Maintain a single register showing which system owns each subscription at any point.
Before approving this approach, ask the partner how cohorts are defined, how billing dates are verified in the target, and how a partially migrated customer base is reported to finance each week.
When the acquirer needs the target's payment gateway to keep processing during a transition, the question is less about subscriptions and more about where payment method tokens live and who can use them. Gateway tokens are generally bound to the gateway account that created them, so moving a customer to a new billing system may require either keeping the original gateway connected or migrating tokens through a gateway-supported process. A common transition pattern keeps the target's gateway live while the acquirer's platform takes over billing logic, then retires that gateway once tokens are moved or customers have re-authorized. This adds a second payment path to monitor and reconcile.
- Token portability: Confirm with each gateway whether tokens can be exported, transferred or re-used by another account, and whether that requires customer consent or a specific format.
- Dual gateway reconciliation: Match settlements, refunds and chargebacks from both gateways to invoices in the billing system, since each gateway reports on its own schedule.
- Rollback path: Keep the target gateway contract and credentials active until the last token is migrated or retired, so payments can continue if the new path fails.
- Card data scope: Confirm which systems receive or hold card data during the transition, because a second gateway path can widen PCI scope.
- Routing rules: Document which customers use which gateway and who approves a change.
Before relying on a token migration, ask the gateway and the partner to confirm in writing what can be transferred and how a failed transfer is detected and retried.
Which open-source platforms fit a billing consolidation
A billing consolidation usually needs one system to hold the target subscriptions, one to move payment tokens between gateways, and one to post results to a ledger. The cards below separate those roles so you can see which platform covers which gap and where each one stops.
Kill Bill as the subscription engine
Kill Bill is an open source subscription billing and payments platform licensed under Apache-2.0. Its plugin model handles payment gateways and tax, so an acquired catalog can often be modeled as its own product and plan set inside the group's instance. Check how the catalog import handles mid-term subscriptions with different billing cycles, proration rules and trial states. Ask the vendor and your implementation partner to confirm which gateway and tax plugins exist for your processors and whether they support the migration path you need.
Lago for usage-heavy catalogs
Lago is a billing engine worth evaluating when the acquired product bills on metered usage, such as API calls, seats synced from events or prepaid credits. It is a different design from Kill Bill, so the choice depends on whether the acquired product's pricing is mostly recurring plans or mostly metered events. Confirm how its object model maps the acquired plans and how it handles historical usage events during a cutover. Do not assume feature parity with Kill Bill for gateway connectors or tax integrations without a written answer from the vendor.
Hyperswitch for moving payment tokens
Hyperswitch is an open source composable payments platform licensed under Apache-2.0. It connects to multiple payment, payout, fraud, vault and tokenization providers, which matters when an acquired business holds card tokens at a gateway the group does not use. Its role is to route and vault payments, not to run subscriptions or invoices. Confirm with the vendor which connectors support token migration in both directions, what format exported tokens take and whether the acquired gateway will release them. Without that, customers may need to re-enter payment details.
Apache Fineract as a ledger partner
Apache Fineract is an open source core banking platform licensed under Apache-2.0. It is relevant to billing consolidation only when the group already runs it for lending or deposit products and needs subscription revenue to land in a loan or account ledger. It does not generate subscription invoices or manage recurring plans. If the group does not already run Fineract, adding it for billing alone usually adds scope without solving the consolidation problem. Confirm the posting interface with your finance team before the design is fixed.
Odoo or ERPNext as ERP partners
Odoo (LGPL version 3 for the community core) and ERPNext (GPL-3.0) both include accounting and sales modules that can receive invoice and revenue postings from a billing engine. Use them as the general ledger partner only if the group already runs one of them as its ERP. Odoo Enterprise features such as hosting and upgrades are a separate licensing decision. Confirm which invoice numbering series and chart of accounts mapping the ERP will accept from the billing platform before cutover, since duplicate or reset invoice numbers are a common consolidation problem.
How the migration runs in phases with a defined output at each step
The sequence moves an acquired product's subscriptions onto the group's billing platform in controlled stages, and each stage closes with a document that finance, audit and engineering can check.
Inventory catalog, subscriptions, tokens and tax rules
The acquired team and DeployOpen engineers export the product catalog, plan and price history, active and paused subscriptions, invoice history, stored payment method references, tax configuration and open credits or dunning cases. Finance confirms which records feed the general ledger and which are operational only. The output is a signed inventory register listing record counts, owners and the source system for each data set, so later reconciliations have a fixed starting point.
Design controls before data moves
Before any migration script runs, the team agrees a change freeze window on catalog and price edits in both systems, defines who may approve access to the migration environment, and sets logging requirements for every privileged action. The change record lists each control, its owner and the evidence it produces, mapped to the IT general control areas that finance and the external auditor expect to see. Sign-off comes from the controller and the security owner.
Map the catalog and obtain sign-off
Each acquired plan, add-on, price point, currency, billing period and tax category is mapped to a product or plan in the group's platform, including rules for grandfathered prices and plans that do not exist in the target. Unmapped items are listed as explicit decisions, not silently dropped. The signed mapping document, approved by product, finance and billing operations, becomes the reference for every later test and for the ledger account mapping.
Trial migration on a subset with reconciliation
A limited set of subscriptions covering each plan type, currency, tax jurisdiction and billing state (active, trialing, past due, paused) is loaded into a staging instance of the target platform. Invoices generated for the next billing cycle are compared line by line with the source system, and differences in amounts, proration, tax and dates are traced to a root cause. The reconciliation report records every variance, its resolution and the rerun results before the full load is approved.
Plan token migration or gateway re-authorization
Stored payment method references are moved only if the source and target gateways or vaults support a documented transfer path with the acquired processor's cooperation. Where a transfer is not possible, the plan records which customers must re-authorize, the messaging and timing for those requests, and how failed attempts are handled. Card data is never exported in clear form. The output is a token transfer plan with success criteria per gateway, reviewed by payments and the security owner.
Cut over with invoice numbering continuity
The cutover runs inside the frozen window. Source subscriptions are paused or closed in the same step that target subscriptions activate, so no customer is billed twice or skipped. Invoice numbering rules define the last issued number in the source, the starting sequence in the target, and any prefix that distinguishes the acquired product, and they are checked against the tax authority's requirements for the relevant jurisdictions. The cutover change record includes timestamps, the operator and the post-load checksums.
Reconcile after cutover and confirm revenue continuity
After the first full billing run on the new platform, billed amounts, deferred revenue balances, credit notes and tax totals are reconciled to the source system and to the general ledger for the affected periods. Finance confirms that revenue recognized for each customer is continuous across the switch date and that no adjustments are unexplained. The reconciliation report, with open items and their owners, is filed with the close package and is the basis for signing off the migration.
Decommission the source and retain archives
The acquired billing system is switched to read-only, access is revoked on a dated schedule, and integrations are removed one by one. Records that must be kept, including invoices, payment histories and communications, are exported into a retained archive with an index that maps each record to its original system and retention basis. Retention periods are set by finance, legal and any applicable rules, such as the SEC record-keeping rule for broker-dealers, which must be confirmed for each entity. The retained archive index is the final output and is stored with the audit evidence.
Keeping invoice numbers and revenue continuous across two systems
The first control to set is non-overlapping invoice series. Before any acquired subscription is migrated, the group should assign the acquired product its own numbering range or prefix in the billing platform, and confirm that the legacy system stops issuing from its old sequence on a fixed cutover date. Two systems issuing from the same sequence, or from sequences that restart, produce duplicate or gap-filled invoice numbers that auditors will question. Finance should also agree in writing which system holds the authoritative copy of each historical invoice, and whether legacy invoices are kept as archived PDFs, re-imported as records, or both. Confirm with the billing platform's documentation how invoice numbering is configured per account or per entity, because the answer determines whether the acquired business can keep its legacy prefix for continuity. Credit notes are where continuity usually breaks. A credit or refund issued after cutover must reference the original legacy invoice number, not a re-generated one, so that the customer, the tax record and the general ledger can all trace the adjustment back to the sale. Map every legacy invoice that may still be credited to a documented reference field, and test a full and a partial credit against a migrated invoice before go-live. Deferred revenue and open receivables carry over the same way: the opening balance of each migrated subscription, its unearned portion and each unpaid invoice must reconcile to the legacy ledger at the cutover date, with the difference explained line by line.
The ledger interface needs the same test discipline as the billing core. Journal entries generated by the billing platform for the acquired product, including revenue recognition, deferred revenue release, tax and write-offs, should be tested against the group's general ledger with the same expected-result scripts used for native products, and reconciled for at least one full close cycle. Treat mapping tables, such as legacy revenue accounts to group accounts, as configuration under change control with an approver and a log. Finally, plan the control scope around the acquisition itself. SEC staff allow management to exclude a newly acquired business from its assessment of internal control over financial reporting, but the exclusion cannot extend beyond one year from the acquisition date or across more than one annual report, and the excluded business and its significance must be disclosed (SEC ICFR FAQ). The group should therefore set a target date within that window to bring the acquired billing process, its access controls and its change management into the group's documented controls, and confirm with its auditors which evidence they will need.
What auditors and regulators will ask to see from the migration
This table maps each evidence item an auditor, regulator or acquirer's compliance team is likely to request to the component that produces it during a billing consolidation. Read it as a checklist to set up before cutover, since several items (access reviews, reconciliations and PCI scope statements) are much harder to reconstruct afterward. Items that depend on the acquired business's jurisdiction, such as DORA or GDPR transfer tools, apply only where the regulatory perimeter reaches the migrated data.
| Evidence item | Produced by | What to confirm before cutover |
|---|---|---|
| Signed catalog mapping | Catalog mapping workbook approved by finance and product owners | Each acquired plan, add-on and price point maps to a group plan, with owner sign-off and effective dates |
| Change tickets for migration scripts | Change management system and version control history for the migration tooling | Every script that touches subscriptions, invoices or balances has a ticket, peer review and a recorded run log |
| Access review for migration accounts | Identity provider and Kill Bill or Lago admin audit logs | Temporary migration service accounts are listed, least-privileged, time-limited and removed after cutover |
| Reconciliation reports of subscriptions and balances | Migration reconciliation job comparing source and target counts, amounts and balances | Variances are explained line by line and signed off before the legacy system is frozen |
| PCI scope statement and SAQ or ROC status for the target environment | Written scope statement from the assessor or QSA, plus the SAQ or Report on Compliance for the target | Gateway tokens replace stored card data in every migrated record, and the validation type matches the payment brands' requirements for the merged entity |
| DORA register entry and exit plan, if applicable | ICT third-party register maintained by the group's risk function, with the migration's exit and transition plan | The acquired entity's ICT arrangements are added to the register and the plan covers any critical or important function |
| GDPR records of processing and transfer tools for non-EEA access | Records of processing maintained by the controller, plus transfer mechanisms such as standard contractual clauses where applicable | Any remote access by a non-EEA acquirer's staff to EU customer data is documented and covered by a Chapter V transfer tool |
| Retained legacy invoice archives | Archived PDFs, invoice registers and numbering history exported from the acquired billing system | Retention periods match the applicable rules, archives are readable and searchable, and the numbering sequence gaps are explained |
How much does a billing consolidation cost, how long does it take and what does it need from us?
What drives the total cost of a billing consolidation after an acquisition?
The cost is driven by the volume and complexity of what moves, not by a single line item. The main drivers are the number of active subscriptions and plans to map, the number of payment gateways holding stored payment method tokens, how much tax configuration must be rebuilt in the target platform, how many custom integrations to the general ledger, CRM or customer portal must be rebuilt, and how clean the source data is. Poor data quality, such as duplicate customer records, inconsistent currencies or missing invoice history, usually adds the most work. The written scope should itemize each of these drivers so the quote can be compared line by line. DeployOpen does not publish prices. Ask for a fixed-scope proposal that separates one-time migration work from any recurring hosting, support or upgrade retainer.
Can our internal team run a billing consolidation without a partner?
Some teams can, particularly when they already operate the target billing platform and have engineers who understand both catalogs and payment flows. The honest test is capacity and independence. The team must map every active subscription, reconcile balances and invoices against the acquired system, keep revenue continuous through cutover, and produce evidence that the migration was controlled. Those tasks compete with the day job of running two billing estates during the transition. Ask internally who will own the cutover runbook, who signs off on reconciliation differences, and who can test rollback. If those answers depend on the same few people, a partner can take the implementation work while your staff keep ownership of catalog decisions and sign-off.
What does a billing consolidation need from finance and legal?
Finance and legal are needed for decisions that engineers cannot make alone. Finance must approve the catalog mapping between the acquired plans and the group's plans, confirm how mid-term subscriptions will be prorated, sign off on invoice numbering continuity and credit note treatment, and agree the reconciliation tolerance for balances and deferred revenue. Legal must confirm the terms under which customer contracts and payment authorizations transfer to the acquirer, whether customer consent or notice is needed for changes to billing terms, and how personal data for the acquired customers may be moved and where staff may access it. Ask both teams to name an approver for each decision in the written scope, with dates tied to the cutover plan.
How long does reconciliation run after cutover?
Reconciliation normally continues after cutover for as long as it takes to close the first full billing and accounting cycles on the new platform and to clear exceptions. The exact length depends on billing frequency, the number of billing cycles that straddle the cutover date, how many payment events settle late, and how many differences appear between the source and target systems. The written scope should state the reconciliation period, the entry and exit criteria, who owns exceptions, and how the parallel run and any rollback decision are handled. No duration is promised here. Ask for the planned reconciliation window in the proposal and compare it against your month-end and audit calendar.
How long does the migration itself take?
The migration timeline follows from the scope rather than from a standard duration. Work typically runs through discovery and catalog mapping, a test migration of a representative subset, rehearsed cutovers, and then production cutover with reconciliation. The factors that lengthen the schedule are the same cost drivers: subscription volume, number of gateways, tax rules, integrations and data quality. Regulatory timing can also matter, for example when a public company must account for an acquired business in its internal control assessment. Ask for a milestone plan with named dependencies, including the finance and legal approvals and any change freeze windows, so the timeline is tied to your calendar.
Would a billing SaaS be simpler than consolidating onto our self-hosted platform?
A billing SaaS can be simpler to adopt when the group has no existing self-hosted billing platform, no data residency constraints and no requirement for direct control of the billing database. It can also reduce the number of systems your team operates. The trade-offs are recurring fees that typically scale with revenue or volume, vendor-controlled migration tooling, and limits on how far you can customize data flows. Compare the total cost over the planning horizon, including the migration itself, the gateway and tax plugins you need, and the exit terms for your data. Requirements for data export, tax and audit evidence should drive the comparison, and the written scope should record the choice and the reasons behind it.
What should we ask for in a written quote for this work?
Ask for a quote built from a written scope that lists each subscription, plan and currency in scope, each payment gateway and the handling of its stored tokens, each tax rule and reverse charge treatment, each integration with the general ledger and other systems, and the data cleansing tasks. The quote should separate one-time migration and testing work from any recurring hosting, support, upgrade or testing retainer. It should state the deliverables for reconciliation, the acceptance criteria, what the client must provide and by when, and what changes trigger a change request. Figures should come from that scope, not from a generic estimate.
Questions to ask an implementation partner before signing
Start with experience, because a partner's track record on this exact migration type matters more than general billing skill. Ask which Kill Bill or Lago catalog and subscription migrations they have completed, how many of those involved moving active subscriptions from a separate acquired billing instance, and which product catalogs they had to remap. Ask how they preserved mid-term billing anchors so that a customer billed on the 14th of the month keeps that cycle after the move, and how they handled proration for subscriptions that were already partway through a term. Request a written description of the mapping file format, the dry-run process, and the sign-off step for each subscription batch. Confirm whether they will migrate payment method tokens by asking each gateway to re-issue or update tokens, or whether they expect customers to re-enter cards, and which option they recommend for each gateway in your estate.
Next, press on the controls that protect financial records during cutover. Ask how they design invoice numbering so that the acquired entity's sequence does not collide with the group's sequence, whether legacy invoices keep their original numbers, and how gaps and duplicates are detected. Ask for their reconciliation method: which totals they compare between source and target (open balances, deferred revenue, credit notes, refunds), who signs off each reconciliation, and what happens when a difference is found. Ask how they will run a change freeze on catalog and price edits during cutover, which roles will hold production access, and how each privileged action is logged so the trail can support SOX IT general controls review if the acquired business falls within your scope.
Finally, cover data location, cross-border access and life after go-live. If the acquired business holds EU personal data, ask who will see that data during migration, from which countries, and under which transfer mechanism, since remote access from a third country counts as a transfer under EDPB Guidelines 05/2021. Ask whether the partner will document processing instructions in line with GDPR Article 28(3)(a) and update records of processing. Ask for an exit and transition plan covering the migrated data, and confirm upgrade, patch and support terms after go-live, including who applies Kill Bill or Lago upgrades and how the partner tests them against your plugins. Confirm each answer in the signed scope, because these commitments decide whether the consolidation holds up under audit.
How DeployOpen scopes and runs a billing consolidation
The sequence below moves an acquired product's subscriptions onto the group's self-hosted billing platform under a written scope, with each stage closing on evidence the finance, security and audit teams can review.
Agree the written scope and deliverables
DeployOpen and the client agree in writing which billing platform, which acquired product lines, which gateways and which connectors are in scope, along with deliverables and acceptance criteria. Engagements of this kind are typically fixed-scope, so the document also states what is excluded, such as tax engine licensing or changes to the acquirer's general ledger. The step closes when the statement of work is signed and the client has named its finance, security and audit contacts.
Inventory the acquired billing estate
The team documents the acquired product's catalog, active subscriptions, price books, invoice templates, numbering sequences, gateway accounts, webhooks and general ledger postings. Where the acquired business sits in the scope of internal control over financial reporting, management may exclude it for a limited period under SEC staff guidance, so the inventory also records which controls it feeds. The output is a reviewed inventory signed off by the client's finance lead.
Map the catalog and tax rules
Plans, add-ons, metered components, currencies and tax settings from the acquired product are mapped to the group's Kill Bill or Lago catalog, with each mapping documented one-to-one or flagged for a business decision. Tax logic is mapped against the tax approach the group already uses, and the client confirms rule ownership. The step closes with a mapping workbook that finance has approved and a list of open decisions with named owners.
Plan payment token and gateway transfers
Stored payment references are reviewed to decide whether they can move between gateways, whether the gateway must re-tokenize cards, or whether customers must re-enter payment details. DeployOpen checks how the group's gateway or orchestrator vault holds tokens and confirms the card data scope with the client's QSA or assessor where applicable. The step closes with a transfer plan per gateway that states the customer communication required and the fallback for any card that cannot move.
Design mid-term subscription migration and invoice continuity
The team designs how active subscriptions carry over mid-billing-period, including anchor dates, proration, credits, dunning state and pending invoices. Invoice numbering is set so the acquired product's numbers do not collide with the group's sequence, and the design keeps prior invoices accessible for audit. Revenue continuity is tested against the general ledger interface. The output is a migration design and a reconciliation specification that finance signs off.
Build, harden and test in a non-production environment
DeployOpen implements and hardens the self-hosted Kill Bill or Lago deployment, its connectors, and the gateway and accounting integrations inside the client's own cloud accounts, data centers or private network. Access controls, change management, logging of user activity and encryption in transit and at rest are configured and tested, and penetration testing scope is agreed if the client requires it. Migration rehearsals run on copies of the data, and each rehearsal produces a reconciliation report of subscriptions, balances and invoice totals. The step closes when the client accepts the rehearsal results.
Cut over and reconcile against the ledger
The production cutover follows the approved runbook, with a rollback path, a freeze on catalog and price changes, and a named decision owner for go or no-go. After cutover, subscriptions, open invoices, payment tokens and ledger balances are reconciled, and exceptions are resolved and logged. The step closes with a signed reconciliation pack that finance, the controller and the client's security lead have reviewed.
Prepare control evidence and hand over support
DeployOpen assembles the control evidence the client's auditors are likely to request, such as change tickets, access reviews, migration reconciliations, invoice approval trails and configuration baselines, and documents them against the client's control matrix. Independent auditors and certification bodies issue any opinions or attestations, not DeployOpen. Runbooks, upgrade procedures and monitoring are handed over, and the client may choose a retainer for upgrades, support and continuous testing. The step closes with a handover acceptance and an evidence index.
