Deep-dive netcracker billing data migration for tier-1 telcos. Bill cycles, invoices, payments, taxes/surcharges, discounts/promotions, partner settlement, prepaid wallets, charging events. Pre-built FBDI emitters, in-flight cycle continuity, end-to-end revenue assurance reconciliation.
Get the billing-data migration wrong and a customer's monthly statement diverges from what was legally issued — which means disputes, regulator complaints and revenue-leakage investigations. Get it right and finance signs off without a hand-wave.
Netcracker Charging & Billing is where the telco's revenue actually gets generated. Rated CDRs from the mediation layer flow in at billions/day, the tariff engine applies rate plans and promotional overlays, the bill-cycle engine groups charges by customer and billing period, the invoice generator issues the bill, the payment engine collects, the AR sub-ledger tracks the receivable, and the partner-settlement engine calculates what the operator owes interconnect carriers, MVNO hosts, content partners and roaming clearinghouses. Each of these stages produces data that has to be migrated to Fusion AR/AP/GL — and the migration has to preserve the exact issued numbers because customers, regulators and partners reconcile against them.
The complexity isn't just volume (though tier-1 telcos generate millions of invoices per bill cycle). It's the lineage. Why did this customer pay USD 27.40 instead of USD 39.99 — which promotion applied, which campaign code triggered it, which discount catalogue version was in effect on the bill date. Why does this invoice line have USD 3.47 of tax — which jurisdiction, which surcharge, which regulatory rule. Why is this partner owed USD 12,847.50 for the quarter — which rated CDRs substantiate it, which interconnect agreement governs it. A netcracker billing data migration has to preserve every one of those lineages through to Fusion or the audit trail breaks.
Syntra ETL ships the lineage-preservation infrastructure as part of the platform. SID-aware discount lineage walking, tax-engine result preservation as transaction-line DFFs, partner-settlement substantiation routed to the archive layer with partner-DFF indexing, rated-CDR-to-invoice traceability via mediation_record_id all the way through. The result is a netcracker billing data migration where finance, revenue assurance, partner management and tax can all sign off because the lineage is intact end-to-end.
Each lineage chain is a sign-off requirement. Break any of them and the audit trail fails.
Why did this customer pay USD 27.40 instead of USD 39.99? Promotion code, campaign, discount catalogue version, eligibility rule — all materialized as Fusion AR Transaction Line DFFs.
Which jurisdiction, which surcharge, which regulatory rule produced each tax line. Issued-invoice lineage preserved exactly (no post-migration re-calculation that diverges from the legal invoice).
Which rated CDRs substantiate the USD 12,847.50 owed to interconnect partner X. CDR substantiation routed to archive with partner-DFF indexing for partner verification.
Multi-currency invoices with FX rate at bill date preserved on the Fusion AR Transaction Line. GL revaluation continues on Fusion side post-cutover.
Customer-owned funds as regulated liability. Wallet balance loaded as customer deposit liability. Top-up/decrement history archived for unclaimed-property reporting.
Mediation_record_id → rated_cdr_id → bill cycle → invoice line → Fusion AR transaction line → Fusion GL journal line. End-to-end revenue assurance chain preserved.
A repeatable load order that respects Fusion's AR/GL dependencies and the billing lineage chains. Skip a step and your invoice load fails on missing customer master or product reference.
AR Transaction Types, Receipt Classes and Methods, Tax Classifications, Surcharge GL accounts, Promotion DFFs, Partner DFFs configured per the COA design. Loaded via FSM tasks.
Customers via FBDI Customer Hub with multi-instance dedup applied. Partners via FBDI Supplier Hub with partner-class DFFs. Loaded in dependency order — masters before transactions.
Rate plans and discount catalogue versions extracted from Netcracker Product Catalog Open API, materialized as Fusion item catalogue plus archive-side promotion catalogue with version-effective dates.
Open invoices, in-progress bill cycles, unapplied payments, AR aging migrated. Customer balances reconciled per BU per currency.
Closed invoices, posted revenue and historical AR aging for the operational window (current FY + prior FY typical) loaded if Fusion is financial target; deeper history routes to archive for SOX 7-year and dispute resolution.
Historical partner-settlement records, settlement-cycle history, partner master ledger loaded. CDR substantiation routed to archive with partner-DFF indexing.
Current prepaid wallet balances loaded as customer deposit liability via FBDI AR Receipt Import. Top-up/decrement history archived for unclaimed-property reporting.
One full bill cycle parallel-run (Netcracker AR sub-ledger vs Fusion AR sub-ledger reconciled to the cent), sign-off pack issued. Revenue feed cuts to Fusion; Netcracker continues operationally.
No bespoke billing-data conversion scaffolding. Just configure scope, run, reconcile.
Headers, lines, discounts, taxes, surcharges, promotional credits from Netcracker Charging & Billing via REST Open API plus direct Oracle DB read for fields not exposed by Open API.
All payment channels (cash, card, direct debit, wallet, prepaid) extracted with original channel preserved as receipt-method DFF on Fusion AR Receipt.
SID Discount and Promotion hierarchies walked, per-line discount lineage materialized as Fusion AR Transaction Line DFFs, full promotion catalogue archived version-by-version.
Issued tax/surcharge lines preserved exactly (no re-calculation post-migration). Tax engine result routed to Fusion AR Transaction Line tax DFFs and Fusion GL Journal tax-segment lineage.
Wholesale interconnect, MVNO host-fee, content-partner, roaming clearinghouse settlement records extracted with CDR substantiation routed to archive.
Wallet balances, top-up/decrement history, bonus-credit lineage extracted. Balances loaded as Fusion customer deposit liability; history archived for unclaimed-property reporting.
A netcracker billing data migration covers the full Netcracker Charging & Billing data footprint: bill cycles (open, in-flight and closed for the operational window plus historical depth), invoices (headers, lines, discounts, taxes, surcharges, promotional credits), invoice adjustments, customer payments (cash, card, direct debit, wallet, prepaid), refunds, write-offs, AR aging and dunning history, partner-settlement records, prepaid balance ledgers, charging events from the rated CDR stream aggregated to revenue grain, rate plans and tariffs in effect during the migration window, discount catalogues and promotional campaign records, tax and surcharge calculations (FCC 800/900, USF, state PUC, VAT/GST). Syntra ETL's netcracker billing data migration ships pre-built extractors and Fusion-target emitters (FBDI AR Transactions, AR Receipts, GL Journal Import) for every one of these domains.
In-flight bill cycles are the most delicate part of any netcracker billing data migration. The pattern is: complete the current bill cycle on Netcracker as normal (rated CDRs continue feeding from the mediation layer, bill generation runs, invoices are issued, customer-facing communication happens on the Netcracker schedule), then migrate the closed bill-cycle data to Fusion as the first cycle of the new revenue feed. The cutover doesn't happen mid-cycle. For the cycle that straddles cutover, Syntra ETL captures intra-cycle deltas via REST Open API watermarks against the Netcracker schema and replays them into Fusion AR at end-of-cycle close so the Fusion AR balance reconciles to Netcracker AR sub-ledger to the cent. Customers experience no service interruption; bill-cycle generation continues uninterrupted.
Netcracker's promotional and discount engine is deep — TM Forum SID models Discount, ProductOffering, ProductOfferingPrice, ProductOfferingPriceAlteration and PromotionalCampaign, layered with eligibility rules, validity periods, decrement schedules and partner co-marketing flags. A netcracker billing data migration has to preserve the audit trail of why a customer paid USD 27.40 instead of USD 39.99 — which promotion applied, which campaign code triggered it, which discount catalogue version was in effect on the bill date. Syntra ETL walks the SID Promotion and Discount hierarchies during extraction, materializes each invoice line's effective discount lineage as DFF attributes on the Fusion AR Transaction Line, and archives the full promotional catalogue version-by-version in the queryable archive for revenue-assurance and dispute-resolution lookups.
Telecom taxes and surcharges are notoriously complex — FCC 800/900 numbers, USF contributions, FCC subscriber-line charge, state PUC fees, e-911 fees, VAT/GST across jurisdictions, content-based taxes for messaging and roaming. Netcracker Charging & Billing calculates these per invoice line via the tax engine (often Vertex, Avalara or a Netcracker-native tax module). For a netcracker billing data migration, Syntra ETL extracts the calculated tax/surcharge lines as they appear on the historical invoices (the calculation is already done — re-calculation post-migration would diverge from the legally issued invoice), maps them to Fusion AR Transaction Lines with tax classification DFFs preserving the original tax engine result, and routes the tax ledger entries to Fusion GL Journals with the same tax-segment lineage. The historical invoice is what the regulator and the customer reconcile against, so preserving the exact issued numbers is non-negotiable.
Partner-settlement records (wholesale interconnect with other carriers, MVNO host-fee settlements, content-partner revenue share, roaming clearinghouse statements, FCC USF passthroughs) sit in Netcracker Revenue Management and get calculated on a settlement cycle (typically quarterly, sometimes monthly). The netcracker billing data migration extracts the settlement records, the underlying rated-CDR substantiation per settlement line, and the partner master, then routes them to Fusion AP for the settlement payments owed, Fusion AR for the settlement receivables, Fusion GL Journals for the inter-company elimination entries, and Fusion Supplier Hub for the partner master records. The rated-CDR substantiation goes to the archive layer with partner-DFF indexing so partners can verify settlement against substantiation post-migration.
Prepaid balances are a special case because they're customer-owned funds sitting on the operator's balance sheet — a regulated liability. The netcracker billing data migration extracts every prepaid wallet balance as of cutover, the full top-up and decrement history for the operational window, the bonus-credit balance lineage (promotional bonuses with different expiry rules), and the regulatory wallet tags (unclaimed-property aging, dormancy flags). The current wallet balances are loaded into Fusion as customer deposit liabilities via FBDI AR Receipt Import (unapplied receipts) or via a custom liability journal depending on the chart-of-accounts design. The full top-up/decrement history goes to the archive layer for customer service queries and regulatory unclaimed-property reporting. Wallet operations continue uninterrupted on Netcracker — only the financial-statement representation moves to Fusion.
Reconciliation runs at four levels for a netcracker billing data migration. (1) Count: invoice headers, invoice lines, payments, adjustments, partner-settlement records — counts match between Netcracker source extract and Fusion target post-load. (2) Sum: gross revenue per product family per period, AR balance per BU per currency, partner settlement per partner per period, tax/surcharge per jurisdiction per period — sum totals match to USD 0.01. (3) Hash: a hash of each invoice's material fields matches between source and target. (4) Revenue assurance: end-to-end chain (Fusion GL revenue line → Fusion AR transaction → Netcracker invoice → bill cycle → rated CDR → mediation record) reconciled per period with original IDs preserved. Sign-off packs are signed, timestamped, retained for SOX 7-year, and shared with finance, revenue assurance, partner management and tax leads for sign-off.
Yes — and this is the operational requirement at every tier-1 telco. Syntra ETL extractors run read-only against Netcracker (REST Open APIs throttled per TM Forum guidance, Netcracker Toolkit batch exports scheduled off-peak, direct Oracle DB read against a Data Guard standby with zero contention). Active bill-cycle generation, invoice issuance, customer-facing communication, payment processing and partner-settlement calculation all continue uninterrupted on the Netcracker production tenant. The netcracker billing data migration runs in parallel — bulk historical extract over weeks, then delta replay via REST Open API watermarks and Oracle DB CDC during the final 1–2 bill-cycle parallel-run window. Operational risk to the live billing engine is zero.
Book a 30-minute scoping call. We'll walk through your billing data footprint, in-flight bill-cycle calendar, partner-settlement cycles, tax-engine integration and prepaid wallet structure — and produce a sized load plan with timeline and budget before the call ends.