The replacement connector returns a company name and address. The demonstration passes. After deployment, however, the CRM creates a second account for a customer it already knows. One import retained the identifier as text; an older spreadsheet converted it to a number; a third system linked the company by its trading name.
For Czech businesses modernizing a CRM, order platform or customer portal, ARES integration is an identity problem as much as an API problem. A technically successful lookup can expose years of inconsistent assumptions about what makes two records the same. Fixing those assumptions is often the work that determines whether the integration actually helps operations.
Start with the official service and its data model
The Czech Ministry of Finance describes ARES as a system for searching economic entities registered in the Czech Republic and links its technical documentation. The official REST API reference exposes services for economic entities, source-register views, notifications and standardized addresses.
That range matters when scoping a connector. A general company lookup and a source-specific view may answer different questions. Choose the service for the fields your application actually needs, and record the source alongside the result. Do not treat every similarly named field as interchangeable simply because it can be parsed into the same text box.
This article recommends an integration approach; it does not claim that an ARES response alone establishes a customer's tax treatment, creditworthiness or authority to place an order. Those decisions require their own supported evidence and business rules.
Preserve identifiers before normalizing names
Treat a company identifier as a structured string with validation appropriate to its source. It is not an amount for arithmetic. Importers should not casually convert it to a number and discard formatting. Preserve the supplied value as well as the validated form so that a rejected match can be explained.
Names are useful for searching but poor as the sole permanent link. A business can change its name, and similar names can belong to different entities. Matching by a simplified name and postcode may produce a confident-looking mistake, especially when historical spreadsheets contain abbreviations or missing address fields.
Create an internal identity map connecting each external source key to the relevant internal entity. Then link customer accounts, contracts and delivery sites to that entity as appropriate. This separates the question of who the company is from how your organization does business with it.
Duplicate accounts are not always duplicate relationships
An illustrative wholesaler has two accounts for one legal entity: one for an installation department and another for a maintenance contract with different ordering contacts. An automatic cleanup routine sees the same company identifier and merges them. Open orders now appear under the wrong commercial arrangement.
Before merging, define which records are true duplicates and which represent intentional relationships. A merge plan should cover permissions, payment terms, delivery addresses and document references. Require a preview of the consequences for active transactions, rather than showing only two rows becoming one.
Historical invoices and contracts need stable references. Updating the current company name should not silently rewrite the label on an already issued document. Preserve the snapshot needed to explain the original transaction while allowing the current account profile to show newer information.
An address update should not move the warehouse
The registered address obtained from a register is not necessarily the destination used by warehouse staff. Model registered, billing and delivery addresses separately. If a customer updates one, show which downstream processes use it before applying the change everywhere.
When an external address is structured, keep those components where they help validation and matching. A single display string is useful for a screen, but it should not be the only stored representation if the next system needs municipality or address identifiers. At the same time, retain the original source response under the agreed retention policy for troubleshooting.
Avoid overpromising automatic correction. An address that cannot be matched should enter a review process. Assign an owner and provide enough context to decide whether the register data, the customer's operational address or the internal mapping needs attention.
Replace the connector with comparison evidence
Build a sample covering active customers, unusual names, missing optional fields and known historical changes. Run the old and proposed normalizers against representative saved inputs where lawful and practical. Compare business meaning rather than raw JSON layout: identity, source, address role and the relationship to existing records.
The new parser should handle unknown fields without failing and avoid inventing values for absent fields. A missing field can mean unavailable information, a different source view or a change in the response model. It does not automatically mean that the old value should be erased.
Document how response errors differ from a genuine no-match result. A timeout must not create an unverified new company automatically. Repeated user submissions after an outage should converge on the same pending onboarding request instead of multiplying accounts.
Notifications need reconciliation, not blind application
If the project uses the available notification services, define how changes are fetched, processed and checked after interruption. A background job should record its progress and expose any backlog. An operator needs to know whether the customer view is current before relying on it.
Apply changes according to field ownership. A register can update the observed registered name; a salesperson's negotiated terms belong to a different process. A source notification should not become broad permission to rewrite the complete account record.
Periodically reconcile a defined sample or portfolio to detect missing mappings and failed processing. The appropriate frequency depends on the business workflow and source constraints. Put that operational decision in the handover rather than burying an arbitrary schedule in code.
Buy an identity-safe first release
Start with one customer-entry path and the fields needed to complete it. The release should search, display a candidate, attach the approved entity to an account and preserve the evidence of that choice. Include an exception queue and an export of the mapping so that ownership remains with your business.
Acceptance tests should cover an identifier with leading zeros, a name change, two intentional accounts for one entity and a source outage during onboarding. Measure duplicate creation, manual correction and the ability to trace an old order after the migration. These outcomes matter more than the number of endpoints connected.
Our guide to database migration without losing records explains the preservation problem. The software quote comparison worksheet helps distinguish connector work from cleanup and migration. TuniCyberLabs can build this through custom software development. Share the customer records and lookup process you need to modernize to define a first release with measurable identity and workflow checks.