Where exactly is the same information entered again?
Take a recently completed case and ask to see both system screens. Record the source system, destination, copied fields and transfer trigger. “Customer approved for billing” is a clear trigger; “connect CRM and ERP” does not yet define a bounded task.
Separate retyping from a necessary decision: copying a billing name is a different task from establishing which legal entity should receive the invoice. In the example above, copying is removed; approval by sales and administration remains.
Which system may change each field?
The mapping above describes initial creation. In this example, the ERP then becomes the system of record for the billing name and address. A later CRM change must therefore not simply overwrite those fields. For each field, decide whether it is transferred once, updated in one direction or submitted for manual review.
The CRM ID provides a unique link for new records. Existing ERP customers first need a verified match: if administration finds a possible customer with the same name and address, it confirms that customer’s ERP number. A name match alone does not trigger automatic creation or merging here.
Existing feature, import or interface?
First check what your existing systems already support. There are three possible approaches for the customer example:
- Existing ERP or CRM feature: use an available standard integration if it covers the required fields, approval and confirmation. Check how it handles repeated transfers too.
- Controlled import: suitable when customers can be transferred in batches at an agreed time. Export columns must match the ERP fields; a person checks the import results and returns the ERP numbers to the CRM.
- Interface: useful when approval should regularly trigger a transfer and return the ERP number automatically. Both systems must permit the necessary access; licences, test access and error reporting are part of assessing feasibility.
What happens with duplicates and errors?
Agree on visible statuses: “Needs review”, “Ready”, “Transferred” and “Error”. In this example, “Transferred” means that the ERP number is recorded in the CRM. Unresolved cases remain visible to administration.
- Duplicate approval: C-184 already exists as K-7021. Return the existing link without creating a second customer.
- Missing confirmation: after a connection failure, first use the external customer reference to check whether the ERP already saved the record. Retry only once the outcome is known. If the ERP cannot support this check, manual investigation is needed.
- Missing required field: without a postcode, C-184 receives the status “Error” and the message “Billing postcode missing”. Administration supplies the information and approves the case again.
- Possible duplicate: an existing ERP customer matches but has no CRM reference yet. Administration checks and links it before the transfer continues.
Check the connection with complete cases
In the test environment, check a complete customer, a customer missing a required field, duplicate approval and a connection failure after saving. Each result must match the agreed behaviour: exactly one ERP customer number or a visible unresolved case with a responsible person. Also check that a later CRM address change does not unexpectedly replace the ERP billing address.
Then compare the previous copying work with the remaining manual queries. Extend the process to changes or additional records only once this handoff works reliably. The structured fields in this example do not require AI.