A billing system syncs with an ERP by sharing one customer and product key, then sending invoices, credit notes, payments, refunds and tax into the ERP's receivables and general ledger, either invoice by invoice or as a daily summary journal. Each object has one system of record, and a daily reconciliation proves billing, ERP and bank agree.
This guide is for finance leads, controllers and CTOs whose invoices are raised outside the ERP: by a subscription billing platform (Stripe Billing, Chargebee and Zuora are examples of the category), a usage-metering service or a home-built invoicing module, feeding an ERP or accounting system such as NetSuite, Microsoft Dynamics 365 Business Central, Xero or QuickBooks. It goes deeper than the short billing section in our ERP and CRM integration guide, which is about the CRM side. If you want the sync designed and built as a managed project, see our ERP integration services page.
Key takeaways
- Agree the system of record for every object before writing any mapping. Most sync problems are ownership problems.
- Customers, products and prices usually flow toward billing; invoices, credit notes, payments, refunds and tax flow toward the ERP.
- Choose invoice-level posting or a summary journal per flow, based on where collections and audit work happen.
- Usage and seat counts need a cutoff, a snapshot and an event ID, or invoices will not be repeatable.
- Every write must be safe to repeat. Duplicate invoices are among the costliest integration bugs in finance.
- Reconcile daily with control totals: billing sub-ledger against ERP receivables, and payouts against the bank.
How do billing and ERP sync?
Billing and ERP sync through a shared customer ID and a mapping from each billing plan or product to an ERP item, revenue account and tax code. Master data moves first, then financial documents follow as events or scheduled batches. The ERP keeps the general ledger; the billing system keeps subscription and invoice detail.
What data should sync between CRM, billing, and ERP for quote-to-cash?
Quote-to-cash data covers accounts, products and price books, contracts or subscriptions, usage, invoices, credit notes, payments and refunds, tax, revenue schedules and journal summaries. Each object moves in one main direction. The CRM starts the deal, billing turns it into invoices, and the ERP books receivables, revenue, tax and cash.
| Object | Main direction | Typical trigger | Notes |
|---|
| Customer or account | CRM or ERP to billing | Deal won, account approved | Carry both IDs on both sides; billing contact and tax ID included |
| Products and price books | ERP or CPQ to billing | Price list approved | Map each plan to an ERP item, revenue account and tax code |
| Subscription or contract | CRM to billing | Order signed | Start date, term, quantity, discount and renewal rules |
| Usage and seat counts | Product or CRM to billing | Daily or before invoice run | Needs cutoff and event IDs (see below) |
| Invoices | Billing to ERP | Invoice finalised | Invoice-level or summary journal |
| Credit notes | Billing to ERP | Credit issued | Reference the original invoice |
| Payments and refunds | Billing or payment provider to ERP | Payment settled, refund issued | Gross amount, fees and payout kept separate |
| Tax | Billing or tax engine to ERP | With each invoice | Tax lines by jurisdiction and rate |
| Revenue schedules | Billing or ERP, one owner | Invoice or contract change | Decide who holds the schedule |
| GL journal summaries | Billing to ERP | Daily or period close | Totals by account, currency and entity |
| Credit status | ERP to billing and CRM | Hold placed or released | Stops new invoices or service on held accounts |
Which system should own each object?
The system of record is the one place where an object is created and changed; every other system reads a copy. Typically the CRM owns the deal, billing owns subscriptions, invoices and usage rating, and the ERP owns the general ledger, receivables balance, tax reporting and cash. Write the choice down per object and field.
| Object | Usual system of record | Other systems | Why |
|---|
| Customer legal name, tax ID, billing address | ERP (finance approves) | Billing and CRM read | Invoices and tax filings depend on it |
| Sales opportunity and contract terms | CRM | Billing reads at order | Sales negotiates the terms |
| Subscription, plan, quantity, renewal | Billing | CRM shows it | Billing calculates every charge |
| Invoice and credit note documents | Billing | ERP holds the posting | Avoids two invoice numbers for one sale |
| General ledger and receivables balance | ERP | Billing shows status | One book of record for finance |
| Cash application | ERP or billing, one only | The other is updated | Two places applying cash causes double credits |
| Revenue schedule | Billing or ERP, one only | The other receives entries | Splitting it makes audit hard |
How do billing systems sync ERPs: real-time, batch or summary journals?
Billing systems sync with ERPs through real-time webhooks or events, scheduled batches, or both, and post either every invoice or a summary journal. Real-time suits customer creation and credit holds. Batch suits high volumes and period close. Most designs combine them: events for master data, daily batches for financial postings.
| Pattern | Best for | Strengths | Trade-offs |
|---|
| Real-time webhooks or events | New customers, credit holds, payment status | Fresh data; sales and support see changes quickly | Must handle retries, duplicates and out-of-order delivery |
| Scheduled batch | Invoices and payments at volume | Predictable load; easy to reconcile per run | Data is hours old; a failed run delays a whole day |
| Invoice-level posting | B2B with collections in the ERP | Each invoice visible in receivables and statements | More ERP records; more API calls |
| Summary journal | High-volume, low-value invoices | Lean ledger; fast close | Invoice detail stays in billing; collections work there |
The choice between invoice-level and summary posting is mostly about where your team chases unpaid invoices. If collectors work in the ERP, they need the invoices there. If billing handles dunning and the ERP only needs correct balances, a daily summary journal by account, currency and entity is often enough, with a drill-back reference to the billing report.
How do you sync user counts from product or CRM into billing?
User counts sync into billing as dated usage or quantity records, taken from the system that actually knows the count. That is usually the product for active users and the CRM for contracted seats. Send a snapshot before each invoice run, give each record a unique event ID, and let billing apply proration rules.
- Pick one source per count. Contracted seats come from the signed order; active users come from the product. Do not let both update the same quantity.
- Fix a cutoff. Define the moment the count is read, in one time zone, so the same period always produces the same invoice.
- Send idempotent records. Each usage record carries an event ID, customer ID, metric, quantity and period, so a resend is ignored instead of billed twice.
- Handle late usage. Decide whether usage arriving after the invoice is finalised goes on the next invoice or triggers an adjustment.
- Show the count back. Put the billed quantity in the CRM so account managers see what the customer pays for.
How do I keep finance data in sync between our ERP and billing system?
Keep finance data in sync by reconciling daily, not only at month end. Compare billing totals with ERP postings by day, account and currency; tie the billing receivables balance to the ERP's receivables control account; and match payment provider payouts to bank deposits. Every difference gets an owner and a reason.
- Daily control totals. Count and value of invoices, credit notes, payments and refunds in billing against what the ERP posted for the same day.
- Sub-ledger to GL. Open billing receivables should equal the ERP receivables control account for the billing customers.
- Cash application. Payments are applied in one system only, then copied. Unapplied cash is a daily exception list.
- Payouts. Post gross receipts, processor fees and refunds separately to a clearing account, so the net payout matches the bank line and the clearing account returns to zero.
For the bank side of this, see bank feeds vs nightly statement imports for reconciliation.
What happens when a billing-to-ERP sync fails?
When a sync fails, a well-built integration retries temporary errors, parks permanent ones in a dead-letter queue for a person to fix, and never posts the same invoice twice. Idempotency keys based on the billing document ID make every write safe to repeat, and version checks stop old events overwriting newer data.
- Duplicate invoices. Store the billing invoice ID on the ERP record and check it before every create.
- Out-of-order events. A payment can arrive before its invoice. Hold it until the invoice exists, or post it as unapplied cash and match it later.
- Partial batches. Save a checkpoint after each confirmed write so a rerun continues rather than starting again.
- Mapping errors. A new plan without an ERP account mapping should stop that record, alert an owner and leave the rest of the batch running.
The patterns are covered in depth in surviving integration failures with idempotency, retries and dead-letter queues.
How does revenue recognition affect the sync?
Revenue recognition decides when billed amounts become revenue, which may differ from the invoice date, for example on annual plans billed upfront. Standards such as ASC 606 and IFRS 15 set the rules. The integration only needs one owner for the schedule; confirm the treatment itself with your accountant.
This guide does not give accounting advice. The integration question is practical: if billing holds the revenue schedule, it sends deferred and recognised amounts to the ERP as journals; if the ERP holds it, billing sends the contract and invoice detail the ERP needs to build the schedule. Either way, changes such as upgrades, downgrades and cancellations must reach the schedule owner.
How do multi-currency and tax change the design?
Multi-currency and tax add three decisions: which system sets the exchange rate, which system calculates tax, and how invoice currency maps to ERP entities and bank accounts. Post invoices in their transaction currency with the rate used, and keep tax lines by jurisdiction and rate rather than as one total.
Let the ERP revalue open balances and book exchange differences, because that is a ledger task. If a separate tax engine calculates tax at invoice time, the ERP should receive the calculated lines, not recalculate them, or the two will drift. Tax rules vary by country, so confirm reporting requirements with your tax adviser.
How do milestone and time-and-materials invoices reach the ERP?
Milestone and time-and-materials invoices reach the ERP the same way as any other invoice, but each line must carry the project ID. Milestone invoices post when an approved acceptance event fires; time and materials invoices post from approved timesheets at contracted rates. The ERP then books revenue, receivables and project cost against that project.
For services firms the billing system, or the ERP's project accounting module, reads approved time and expenses, applies the rate card from the contract, and raises invoices per billing period. Milestone invoices need a clear approval event, such as a signed acceptance. Retainers and caps (for example "not to exceed") belong in the contract record, so billing can warn before an invoice exceeds them. For the CRM opportunity to project set-up, see ERP and CRM integration.
Should you use a native connector, an iPaaS or a custom integration?
Use a native connector when your flows match what it supports, an integration platform (iPaaS) when you connect several systems and want shared monitoring, and a custom integration when you have unusual billing rules, high volumes or strict reconciliation needs. Many companies start with a connector and add custom flows later.
| Option | Fits when | Watch for |
|---|
| Native connector | Standard objects, one entity, simple pricing | Check in vendor docs which objects, fields and directions it supports |
| iPaaS | Several systems, in-house team to maintain flows | Per-task pricing and limits; you still design the mappings |
| Custom integration | Usage pricing, multi-entity, project billing, strict controls | Needs an owner for support and changes after launch |
Before relying on any connector, confirm its scope in the vendor's current documentation: which objects sync, in which direction, and how it handles credit notes, refunds and multi-currency. Our system integrations page explains how custom flows are built and monitored.
Illustrative example
This example is hypothetical; the company and figures are invented. A software company bills monthly subscriptions in two currencies from a billing platform and keeps its books in a cloud ERP. Customers are created in the CRM, approved in the ERP, and pushed to billing by event. Each night a batch posts a summary journal per currency and a list of invoices over a set value at invoice level, because those are the accounts finance chases.
One morning the control report shows 212 invoices worth 48,300 in billing against 47,900 posted in the ERP. The difference of 400 is one invoice finalised after the batch cutoff. It posts in the next run, the report clears, and nobody edits the ledger by hand.
What does a rollout plan look like?
A rollout moves from decisions to one flow, then to the rest, with reconciliation running from day one. Each step has an exit test before the next starts. The schedule comes from your volumes, systems and rules, not from a template.
- Map. List every object and field, the system of record and the direction, using the tables above.
- Clean. Match customers across systems and fix duplicates before the first sync.
- Build the first flow. Usually customers plus invoices, with logging, alerts and the daily control report.
- Test on real cases. Credit notes, refunds, partial payments, upgrades mid-period, another currency, a failed run.
- Run in parallel. Post to a test company or compare outputs for at least one billing cycle before switching off manual entry.
- Add flows. Payments, usage, revenue journals and credit status, one at a time.
- Hand over. Name an owner for the exception queue and the monthly review of mappings.
When this is the wrong approach
A full billing-to-ERP integration is the wrong approach when invoice volume is low enough for a monthly import, when the ERP can raise the invoices itself, or when pricing is still changing every few weeks. It is also premature if customer records are not clean: syncing them only spreads the duplicates faster.
If you raise a small number of invoices a month, an export from billing and a reviewed import into the ERP may be all you need. If your ERP already has a billing module that handles your pricing, moving invoicing into it can remove the integration entirely.
Glossary: quote-to-cash, the process from quote to collected payment; system of record, the one system where an object is created and changed; summary journal, one ledger entry that totals many invoices; idempotency key, an ID that makes a repeated request have no extra effect; dead-letter queue, a store for records that could not be processed; sub-ledger, a detailed ledger whose total feeds a general ledger control account.
How Timeline Digital approaches billing-to-ERP integration
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, that builds integrations between billing platforms, CRMs and ERPs as managed projects. We start by mapping your objects and system of record, then build a free pilot of the key modules, such as customer and invoice sync, that your team tests before you decide on the final agreement. There is no fixed timeframe: the schedule for a billing-to-ERP integration is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days, and with 1,200+ developers we have the capacity to deliver a focused system in as little as 2 weeks. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Timeline Digital does not publish prices for custom software, because every project is custom. See ERP integration services to start.