When the finance department generates quarterly reports and discovers discrepancies between the contract amount in the CRM, billing system data, and the signed PDF document, an architectural solution is required. Instead of manually reconciling lines, an architect should select one system as the reference source for a specific attribute. Setting up automatic synchronization allows for the preservation of existing IT infrastructure and the familiar workflows of various departments.
When systems disagree: the price of conflicting data
Consider an illustrative scenario with invented amounts: the commercial director looks at the CRM dashboard and sees a total amount of concluded deals of 10 million hryvnias. At the same time, the operations director receives a report from the billing system where only 8.5 million is recorded. The financial controller, pulling primary documents from the electronic archive, finds confirmation for 9.2 million. All three systems are working properly, do not produce errors, and are updated regularly, but the lack of a unified view of the data stops financial decision-making and blocks bonus payouts.
This problem is not solved by a simple directive to use only one program or an attempt to move all business processes into one monolithic ERP system. Each department uses the tool that best suits its specific tasks. Sales managers need a flexible CRM for quickly recording agreements and managing the pipeline, accounting needs a rigid billing system for generating tax invoices and bills, and lawyers need a reliable archive for storing signed originals in compliance with legal requirements.
The consequence of such isolation is regular cross-functional meetings where managers, instead of discussing strategy, spend hours figuring out whose figure is correct. Manual data reconciliation requires significant back-office resources, creates a risk of human error, and delays the closing of the reporting period. Practice shows that moving to a single source of truth for critical records can significantly free up staff time. For example, when the bank MAIB automated archive processes and made the electronic archive the single source of truth for all banking systems, it allowed for significant optimization of operational costs.
In addition to direct administrative costs, data conflict creates commercial risks. If a client receives an invoice that does not match the final agreements recorded in the contract, it leads to payment stoppages and reputational losses. Therefore, the IT director's task is not to choose a universal system, but to build an architecture where each critical field has a clearly defined owner, and all other systems act only as consumers of this information.
Sources: [3]
Anatomy of discrepancies: event time and field definition
To eliminate data conflict, it is necessary to trace its mechanism at the architectural level by checking the difference in the time of event recording and differences in business definitions of attributes. In the contract amount example, each platform records its own stage of the deal's lifecycle, using separate triggers for database updates. This creates a trade-off between the speed of data updates and the accuracy of reflecting the current state of the deal in different systems.
In the CRM, the 'Contract Amount' field is updated the moment a manager moves a deal to the 'Successfully Closed' status. This is the expected value based on preliminary commercial agreements. In the electronic archive, the amount is recorded at the moment a qualified electronic signature is applied to the final version of the contract, which may have changed after lengthy legal review and reconciliation of discrepancy protocols. The billing system registers the amount only when an actual invoice is generated, which may account for proportional discounts for a partial month of service provision or penalties.
Thus, the systems are not wrong—they are simply answering different operational questions. The CRM shows a commercial forecast, the archive shows a legal obligation, and the billing system shows an actual payment demand. Conflict arises when management attempts to use the forecast figure from the CRM for rigid financial planning, ignoring legally significant data from the archive.
A data architect must distinguish these concepts at the level of the corporate data model. Instead of one universal 'Amount' field, three separate attributes should appear in the integration bus: projected cost, approved cost, and amount payable. Only after such semantic separation can one proceed to assigning owner systems for each of these metrics, avoiding the overwriting of reliable data with preliminary estimates.
Selection matrix: how to define an authoritative source
Defining a System of Record does not mean choosing one platform for all of a company's data. The decision is made at the micro-level—for each specific attribute separately. The architect must analyze which system is the initiator of the final, irreversible state change for this field and grant it write access, putting all other systems in read-only mode.
For the 'Legally Approved Contract Amount' metric, it is necessary to compare alternatives. By choosing the CRM, the company gains display speed but critically loses accuracy, as data is entered there manually by managers and often before all legal checks are completed. By choosing billing, the company gains transaction accuracy but loses the overall picture of obligations, as invoices are issued in parts throughout the year, rather than for the entire contract amount at once.
Assigning the electronic archive as the reference source for the base contract amount is appropriate because that is where the document is signed with legal consequences. This creates an operational trade-off: data in other systems will only be updated after the signing procedure is completed, which may take several days. This approach supports the generation of financial reporting based on verified facts, although it slows down the availability of final figures for related departments.
If an additional agreement is signed to the contract that changes the amount, this process is also initiated and completed in the archive. The reference source records the new version of the document, registers the attribute change, and broadcasts the updated value to subordinate systems. This approach makes it impossible for a manager in the CRM to arbitrarily increase the deal amount to meet KPIs without appropriate legal confirmation.
| Candidate System | Data Update Trigger | Architectural Decision |
|---|---|---|
| CRM System | Manager changes deal status | Use exclusively for 'Projected Amount' field |
| Electronic Archive | Signature applied to final file | Approve as reference source for 'Approved Amount' field |
| Billing System | Generation of first invoice | Use for 'Amount Payable' field |
Integration instead of centralization: setting up data exchange
Once the reference source is defined, the next step is the technical implementation of data transfer. Instead of forcing managers to switch from the CRM to the archive to check the final amount, the architecture must ensure automatic background synchronization. For this, an integration layer is used, which connects isolated platforms via standardized exchange protocols.
UnityBase can serve as an integration node: platform business objects can expose programmatic interfaces, while connectors call external services. Its change log records who changed data or a workflow state and when. In this scenario, once the signed document is stored in Scriptum.Repository, a workflow event sends the approved contract attributes to connected systems.
The trigger transmits the approved contract amount to the CRM and billing system via API, while the field in the subordinate systems is blocked for manual editing. The integration layer must handle errors: if the CRM is temporarily unavailable, the message is queued and delivered after the connection is restored. This ensures data consistency, requiring thorough testing of retry mechanisms.
If the architecture of the subordinate system does not allow for hard-blocking a field at the interface level, the integration platform's audit trail will record any attempts at manual intervention. The next scheduled synchronization will overwrite unauthorized changes with the reference value from the archive. Such a mechanism not only ensures the reliability of reporting but also provides auditors with clear proof that the company's financial indicators are protected from manipulation at the individual user level.
Action checklist
- Compile a list of all IT systems where the conflicting business metric is stored, displayed, or edited.
- Define the exact operational trigger that records the final and irreversible value of this field (e.g., applying an electronic signature or executing a transaction).
- Assign the system that processes this trigger as the single System of Record for the specific attribute.
- Set up a one-way API integration to transmit the reference value to all other subordinate systems.
- Block the ability to manually edit the synchronized field in subordinate systems at the access rights or interface level.
Questions and answers
What should I do if the subordinate system does not support blocking a field for manual editing?
If the system interface does not allow making a field read-only, configure regular overwriting of this attribute via API from the reference source and activate change auditing. Any manual change will be detected and automatically corrected during the next synchronization, and the responsible manager will receive a notification about the process violation.
How should I act when historical data in different systems already diverges by significant amounts?
Do not attempt to automatically overwrite all historical discrepancies with a script, as this may affect closed financial periods. Set a transition date for the new architecture, from which the reference source becomes the priority for new records. For old discrepancies, create a separate report and pass it to the finance department for settlement in accordance with accounting policy.