How do you connect CRM to billing?

You connect your CRM to billing by deciding which moment in the CRM should produce an invoice or subscription (usually the won stage, with mandatory fields), which data is handed over for it (customer, products, prices, start date, invoicing schedule), and which system leads after the handover. The technology, whether a standard connector, an integration platform or a custom API integration, is the smallest decision. Most integrations fail on agreements and data quality, not on code.

What should the integration solve?

Without an integration, the handover from sales to billing runs through people. A salesperson sends an email, fills in a form or mentions it over coffee. Someone in finance creates the invoice or subscription. That works until volume grows or someone goes on holiday. Then deals sit untouched, amounts are retyped and start dates end up wrong in the system.

An integration has to do three things:

1. Make sure every won deal becomes an invoice or subscription. The largest leak, and the easiest to prevent.
2. Make sure the data is correct. Right customer entity, right products, right prices, right date.
3. Make sure changes after the sale come through. Upgrades, downgrades, renewals and cancellations.

The first is relatively simple. The third is where most integrations fall short.

What are the five design choices?

1. What is the trigger?

Which moment in the CRM sets invoicing in motion? Usually the won stage. But in many CRMs, won means something different to each salesperson. Define what it means: a signed contract in place, an order confirmation received, or agreement by email. And make the fields billing needs mandatory at that stage. A deal without a customer number or start date should not be able to move to won.

2. What data is handed over?

At a minimum:

• Customer, preferably through a customer number that exists in both systems. The billing system leads for billing address, company registration number and VAT number.
• Products or services, as lines, not as one total. With item codes that exist in billing.
• Prices and discounts, per line. Discounts with an end date where there is one.
• Start date and term.
• Invoicing schedule: one-off, instalments, monthly, annually in advance.
• Reference: a deal or contract number that appears on the invoice, so you can reconcile later.

3. In which direction?

From CRM to billing, with only status information flowing back. After the handover, billing leads for what is invoiced. The CRM may see what was invoiced and paid, but must not overwrite the billing system. Two-way synchronisation, in which both systems may change each other, leads to conflicts where nobody knows which version is right any more. Which system leads for which data item is covered in which data source leads for revenue.

4. Draft or final?

Does the integration create a final invoice straight away, or a draft that someone in finance checks and sends? For most B2B companies, a draft is the sensible start. Finance sees every new invoice before it goes out, and the integration removes the retyping. Only once the integration has run without errors for months can you move to sending standard deals directly.

5. What happens with changes?

A deal adjusted after it is won, an upgrade on a running subscription, a cancellation of a module. Three options:

• The integration processes changes automatically. Powerful, but error-prone.
• The integration creates a task for finance for every change. Safe, but dependent on follow-up.
• Changes are made only in the billing system. Then the CRM must be able to see them, or it falls behind.

The second option is usually the best start. It prevents an upgrade getting stuck in the CRM without billing knowing about it.

What are the technical options?

For companies where billing is part of the ERP, this overlaps with how to connect CRM to ERP. If you work with quotes that set prices and configurations, the integration should really start at the quote, as described in quote-to-cash explained.

Where does it go wrong?

• Duplicate invoices. A deal is marked as won twice, or the integration runs twice. Make sure each deal can produce only one invoice, using the deal number as a check.
• Unknown customers. The customer exists in the CRM but not in billing. The integration creates a new debtor with an incomplete address or no VAT number. Have finance check new debtors first.
• Unknown products. A salesperson uses a product line that does not exist in billing, or types a free-text description. The integration fails, or creates a line without an item code.
• Silent failures. The integration fails and nobody notices. An integration without an error alert to a named person is a leak with extra steps.
• Manual corrections on one side. Finance adjusts the invoice, the CRM stays at the old amount. At the next reconciliation the difference is back.

Worked example

Worked example: suppose you have 40 won deals a month. Manual handover takes twenty minutes per deal on average: looking up data, checking the customer, creating the invoice, verifying. That is more than 13 hours a month. Suppose also that 1 in 50 deals is left untouched or copied across wrongly, with an average deal value of EUR 20,000.

• Time: 13 hours a month, more than 150 hours a year.
• Revenue at risk: almost 10 deals a year, together EUR 190,000, part of which is discovered later and part never.

An integration removes most of both. It does not replace the check afterwards. The error rate and times are assumptions for the example.

Step-by-step plan

1. Define won. With the mandatory fields.
2. Align customer and product lists. Customer numbers and item codes that exist in both systems.
3. Choose the trigger and the format. Draft or final, one-off or subscription.
4. Build the integration for the simplest deal type first. Standard products, standard prices.
5. Send error alerts to a named person. Not to a shared inbox.
6. Run in parallel for a month. The integration creates drafts, finance creates invoices manually and compares.
7. Extend to more complex deals. Instalments, subscriptions, discounts.
8. Keep the monthly reconciliation. See CRM-to-billing reconciliation explained.

Steps 1 and 2 are the most work. An integration on a CRM with incomplete fields simply copies the errors faster. So check the CRM data itself first, preferably continuously, as in how to check CRM data automatically.

A connection between CRM and billing is one of the building blocks of a single source of truth for revenue. It prevents most of the differences; reconciliation catches the rest.

Frequently asked questions

Does the integration need to be real-time?

For invoicing, that is rarely necessary. An integration that runs every hour or every night is more than enough. What matters more is that errors are reported immediately.

Can the CRM invoice by itself instead of using an integration?

In simple situations, yes. Once you have an accounting system that must lead for debtors, VAT and revenue recognition, you still need an integration, and with it the reconciliation.

Who should own the integration?

Someone who understands the process side of both sales and finance. The technical build can sit with IT or a partner, but the rules (when, what, which system leads) belong to the business.

What do I do about old deals that were never invoiced?

A new integration will not catch those. Do a one-off full comparison of won deals against invoices over the past period, then start the integration from a clean base.