Connect CRM and accounting: agree customers, orders and invoice boundaries

Choose one useful route

A sensible first route might make an internally approved CRM order available to accounting as a draft. It contains the agreed customer reference, description and line items, and an employee reviews the result. This automates handover without immediately delegating every financial action. Identify the precise triggering status and what can still change after approval, because those choices define what the integration is actually authorised to do.

Another route might return a business payment status to sales. Ask what information is needed for the next action. A document reference and status may suffice, while bank information and complete accounting entries add little value. Restrict the exchange to its purpose. Copying more information increases the work of validating meaning and permissions, even when the technical change appears to be only a few additional fields.

Make customer identity explicit

A name can change and an email address can be shared by several people. Do not silently treat those values as infallible identity keys. After a relationship is confirmed, preserve the record reference from each application. Include the destination administration as part of that mapping. The same customer number in a second administration may identify a completely different organisation.

Prepare a reviewed mapping for existing customers. Ambiguous matches should be assessed instead of automatically merged. In a fictional example, Northhaven exists as a CRM prospect and as an accounting customer with a different spelling. An employee confirms the relationship and records the match. A subsequent change of company name can then reuse the confirmed identity instead of creating another customer simply because the text no longer matches.

Separate people, organisations and addresses

A contact person, purchasing organisation and invoice address are different entities. Document how the chosen products represent them. A customer with two operating locations may have central invoicing but need a local project contact. Copying the first available address can produce a technically valid record that is wrong for the commercial transaction. A successful API response does not resolve that business distinction.

Assign meaning and ownership per field. For example, the CRM could own the project contact, accounting could own approved billing details and the integration could retain the confirmed mapping. This is one possible arrangement, not a universal standard. Moneybird documents contact operations and customer references separately; other products may have different boundaries. Review the current documentation for the actual products rather than assuming the example applies unchanged.

If both applications can change the same data, you need explicit conflict rules: Synchronise data without uncontrolled overwriting.

Moneybird API: Contacts ↗

Write a field contract

Create a mapping with source field, destination field, transformation, owner and response to missing information. Include dates, currencies, units and rounding rules where relevant. An order quantity of three is ambiguous if one application means hours and the other means half-days. The process owner should confirm the intended meaning before a developer implements the conversion or chooses a default value.

An empty optional telephone field may be acceptable, while a missing mandatory relationship reference may block the transfer. Make the difference visible in an actionable exception queue. Avoid generic messages that force employees to inspect every field manually. Record whether an empty source value is allowed to erase existing destination information or should instead be interpreted as no change. That small decision can prevent widespread accidental loss of useful details.

Define the invoice boundary

Creating a draft, finalising it, sending it and processing a correction are separate actions. Describe them individually. Decide which can be requested from the CRM and which must be approved in accounting. A sales status such as won does not automatically mean that the invoice contents have been reviewed or that the organisation has authorised immediate dispatch to the customer.

Use three fictional trial orders: a normal order, an order whose customer reference changes and one cancelled after approval. Agree the expected result in advance. A cancelled order might require review when a document already exists. Have the responsible financial person determine the appropriate document treatment. A technical data schema cannot decide which accounting or tax correction is appropriate in the actual circumstances.

Give payment status a clear meaning

A simple paid indicator can be ambiguous when payments are partial, a document is disputed or several invoices relate to one order. Identify the question the account manager needs to answer. Deciding whether to prepare another delivery may require different information and authority from simply avoiding an unnecessary reminder. Do not transfer a status without agreeing how it will be interpreted.

Show when the status was last refreshed and identify its source document. During an interruption an older value should remain recognisable as stale. Unknown is different from unpaid. Design the interface and working instructions so an employee can inspect the source before contacting a customer based on outdated information. Avoid presenting a failed refresh as evidence that a customer has not met an obligation.

Introduce existing records in a controlled way

Separate initial customer matching from daily order processing. Decide which records belong in the initial set and which inactive relationships stay outside it. List uncertain matches, duplicate customer numbers and missing information. Assign reviewers and determine which issues must be resolved before launch. A broad clean-up assignment should not be assumed to be included within a small integration project.

Trial the initial load with a limited representative selection. Check content as well as counts: whether the right organisations were linked, addresses preserved and no unintended documents created by a test. Retain mappings so a second execution reuses earlier decisions. A restart should continue controlled work rather than repeat every attempt as if nothing had previously happened. Keep rejected items visible until someone resolves or explicitly excludes them.

Test handover and daily reconciliation

Test valid orders alongside missing fields, repeated submissions, an unavailable accounting service and an uncertain response after document creation. Describe the expected business state: one identifiable draft for the right organisation, or a useful exception without an unintended next action. Technical success notifications alone cannot establish that the transfer has served the operational requirement correctly.

Agree how missing work becomes visible. For example, reconcile approved source orders against confirmed destination references for a suitable period. Choose that period around the business process instead of inventing a universal interval. Give employees an owner, a review queue and a recovery procedure. The integration should support collaboration between sales and accounting, rather than conceal their different responsibilities behind uncontrolled automatic overwriting.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• API integration ↗
• CRM integration ↗

Questions about this topic

Continue with a related question