Integration of electronic document management and financial systems: benefits and features
During a presentation for clients of the Intecracy Group consortium, the Director of IQusion IT LLC, Serhii Balashuk, highlighted the practical principles of combining electronic document management systems with enterprise financial and accounting systems. According to the speaker, “integration of electronic document management with financial systems opens up new opportunities for optimizing business processes and increasing company management efficiency.” Combining an approved contract, invoice, or acceptance certificate with accounting registers according to agreed rules reduces manual data transfer, speeds up regular reconciliations, and makes financial obligations clearer for control.
Architecture of Connection Between Document Management and Financial Accounting
In a project with Megapolis.DocNet or another EDMS, it is first determined which documents and details will be transferred to the financial system. This may include information about the contract, counterparty, amount, or payment deadline. The goal is to reduce re-entry of already verified data. The list of fields, transfer timing, and error handling are agreed upon for specific software versions.
A hypothetical scenario may begin with invoice approval. After verification, data is transferred to the accounting system, where responsible employees perform actions prescribed by the accounting policy. Reverse exchange can notify the EDMS of document acceptance or settlement status. The statuses “approved”, “posted to accounting”, and “paid” must be distinguished: completion of internal approval does not yet mean the transfer of funds.
The presence of a ready-made connector and its compatibility are checked separately. If customization is required, the requirements for system integration specify supported operations, message format, persons responsible for both systems, and the procedure for verifying exchange after updates.
Document approval, its reflection in accounting, and payment execution are distinct stages. Integration must link their statuses and preserve the established control of each stage.
Maintenance of Reference Data and Master Data
If the same supplier has different records in two systems, reconciliation requires mapping rules. Before launch, duplicates should be cleaned up and identifiers for counterparties, contracts, and documents should be agreed upon. A matching organization name alone is not a sufficient rule for automatic mapping.
The master directory of counterparties can be maintained in the financial system or another agreed source, such as a centralized master data management (MDM) database. An obligatory one-way data flow should not be assumed for all enterprises, as the update regulation depends on internal accounting policy. If the financial system is selected as the primary source, all new bank details, addresses, and tax details are first registered and verified by accounting, after which they are transferred to document management.
The composition of data depends on the document type. For an invoice or acceptance certificate, it is advisable to align the following fields:
- Unique EDRPOU code or registration number of the counterparty.
- System identifier of the organization card in the MDM database.
- Total amount of the document with breakdown of VAT rate and VAT amount.
- Settlement currency and, if necessary, exchange rate with an agreed date determination rule.
- Clear document status in the approval route.
- Document and version identifier to recognize retransmission.
Separately, it is determined who can modify bank details and how such changes are verified. Aligned reference data and mapping rules reduce the risk of duplication, while an error log helps locate records requiring manual clarification.
Data Exchange Protocols and Idempotency Requirements
Data exchange between document management and accounting systems can be carried out via web services (REST API) or through periodic file transfer in XML formats. The choice of mechanism depends on technical capabilities and specific software versions.
W3C SOAP 1.2 (2007) describes a model for exchanging structured XML messages. Use of the standard does not define the content of accounting details or rules for their verification. These, as well as authorization of exchange participants, must be described in specific project requirements.
An important technical aspect when exchanging data using HTTP is ensuring idempotency. According to the IETF RFC 9110 (HTTP Semantics) specification, the intended effect on the server of multiple identical idempotent requests is the same as for a single request. However, HTTP technical idempotency is not identical to business idempotency. Repeating a network request does not mean that the system can re-execute payments or create new liability entries without verification.
Consider a communication failure after transmitting an invoice: no response was received, although the other system might have already accepted the document. In such a situation, the processing state should first be established. The mechanism for recognizing a duplicate message by document identifier needs to be implemented and tested separately. Re-sending the request itself should not create a second obligation.
Document Processing Scenarios and Pilot Project Testing
A pilot project should verify both routine exchange and error conditions. Expected behavior should be described in advance for the following situations:
- Unknown counterparty. Who checks the record, where is the error displayed, and under what conditions can exchange continue?
- Incomplete or conflicting details. How is a document rejected or postponed with an error in the VAT amount or required field to avoid incorrect posting?
- Amount change after approval. How is the previous version saved, and when is re-approval required?
- No response. How to distinguish a message delay from document rejection and verify whether it has already been accepted?
- Cancellation and retransmission. Which actions are allowed prior to posting, and which require separate correction in accounting?
During testing, not only success messages are verified, but also actual records in both systems. For each scenario, initial data, expected result, and the person responsible for resolving discrepancies are documented. This provides accounting with a clear method for integration acceptance.
Legal Validity, Segregation of Rights, and Executive Benefits
Law of Ukraine No. 851-IV as effective at the beginning of 2024 establishes requirements for electronic documents and originals. A scan of a paper document by itself is a copy. In the project, it should be defined where the original is stored, what exactly is transferred between systems — the document or only its details — and how participants obtain proper access to the primary source.
Law of Ukraine No. 2155-VIII “On Electronic Identification and Electronic Trust Services” as effective as of January 1, 2024 gives qualified electronic signature (QES) the legal effect of a handwritten signature. In the process, the signatory’s authority and the signature verification procedure are determined. Transferring the “approved” status between applications by itself does not replace the necessary signing of the document.
Properly configured interaction between systems provides concrete benefits to employees at various levels:
- To the Accountant: reduces time spent on manual invoice entry, simplifies monthly reconciliation of primary documents, and lowers the risk of registering documents with invalid details.
- To the Chief Financial Officer: helps compare actual and planned obligations, aids in better cash flow planning, and helps check payments against approved contracts.
- To the Enterprise Executive: provides a transparent picture of document progress through all approval links and reduces delays when approving critical agreements.
The result is evaluated based on data entry and reconciliation time, number of retransmissions, and the proportion of documents requiring manual correction. Access to financial details and actions must be restricted by authority and verified prior to launch. Thus, integration becomes a manageable workflow for accounting and executives.
Questions and answers
Which system should maintain the master contractor directory?
This is determined in the project. The source can be the financial system or another agreed database with personnel responsible for verifying and updating records.
What to do if the other system did not respond to the request?
Check the document processing status. The lack of a response does not mean that the document was not accepted; retransmission should account for duplicate control.
Is there a universal connection to any ERP?
Compatibility is verified for specific products and versions. Data composition, exchange rules, and required customization are determined prior to launch.
Sources
- Law of Ukraine No. 851-IV “On Electronic Documents and Electronic Document Management”, version effective as of early 2024
- Law of Ukraine No. 2155-VIII “On Electronic Identification and Electronic Trust Services”, version effective as of 01.01.2024
- IETF RFC 9110 (HTTP Semantics)
- W3C SOAP 1.2 Specification
