Data reconciliation between bank, Treasury, and accounting

Discrepancies during the reconciliation of payment documents between bank statements, State Treasury Service registers, and accounting system records lead to delays in closing reporting periods. Traditional methods of manually matching transactions by amount and date are losing effectiveness due to increasing transaction volumes and the financial sector's transition to new data exchange standards. Organizations must restructure control processes to ensure accurate matching of every payment with checks for duplicates and the completeness of financial records.

To solve this task, it is advisable to use an integrated scheme where the accounting system acts as a central verification hub. This allows for the consolidation of data from various external sources into a single interface, simplifying the identification of discrepancies. Instead of chaotic reconciliation of paper or disparate electronic registers, the finance department receives a structured flow of information that undergoes automatic primary verification for compliance with basic details.

Identification of payment operations in the Electronic Payment System

Reconciliation requires an identifier that can be traced in both systems. In payment messages, such a detail can be the UETR, but its presence, location in the file, and usage rules must be verified against the documentation of the specific banking interface. The technological status of a payment's movement should be separated from the statement and its reflection in accounting. These data points answer different questions and should not automatically substitute for one another.

To obtain detailed information about the movement of funds in accounts, the camt.053 account statement message is used, the structure of which complies with the ISO 20022 standard. This format contains mandatory and optional fields that ensure accurate identification and reconciliation of payments at the banking institution level. The accounting system must support the import of such statements and perform checks on file versions and formats for correct data reading. In the absence of a stable unique key in the received document, the system should be configured to pass ambiguous operations to a responsible specialist for review, avoiding automatic merging of records based solely on amount or date, as this can lead to distorted financial reporting.

Designing interaction between the bank, the Treasury, and the accounting system

In a project using "A5 Accounting," one should first check the interfaces and exchange formats available for the installed version. The integration scheme should include only confirmed capabilities. If file conversion or a separate adapter is required, its rules, owner, and update procedure must be explicitly described. A shared register of reconciliation results helps to see which records have been accepted, rejected, or sent for review.

The technical team must define the transactional boundaries of the import. It is necessary to understand whether loading can be repeated after a partial failure, how processed records are marked, and where the reason for rejection is stored. Additionally, logging of changes to matching rules should be checked: without a configuration history, it is difficult to explain why identical input data produced different results on different days.

When designing a three-circuit scheme, it is important to clearly delineate areas of responsibility between systems. The accounting system is responsible for generating primary documents and controlling the existence of accounting entries. The banking circuit ensures the direct execution of payments and the provision of technological statuses. The Treasury circuit is responsible for servicing budget funds and registering obligations. Integrating these circuits at the API level allows for prompt confirmation of operations, but the rules for automatic posting and the authority of responsible persons must be agreed upon for the specific process.

Configuring exchange via RSS and version verification

Interaction with State Treasury Service bodies is carried out through the Remote Service System (RSS) "Client Treasury – Treasury." This system provides electronic document management and data exchange, including the import and export of payment instructions and obligation registers in defined formats. To configure the exchange, one should check the supported formats and versions in the documentation of the RSS and the installed accounting system.

It should be noted that each exchange format has its own specific features, so its implementation requires prior verification of file versions and formats. The Economic Expenditure Classification Code (KEKV) is used for budget accounting, but it is not a unique payment identifier and cannot be used as a single key for automatic matching. To avoid errors when importing documents, it is necessary to strictly adhere to the State Treasury Service's requirements regarding the structure of exchange files. It is recommended to conduct regular testing of import and export procedures using dummy examples before starting industrial operation of updated modules to timely detect possible discrepancies in the data structure.

• Format version verification

  Verify that the structure of exchange files complies with the current requirements of the Treasury RSS and the specifications of the supported version.

• Analysis of identifier availability

  Ensure that stable matching keys and processing rules for cases without such a key are defined for incoming records.

• Testing on dummy data

  Perform test loading and unloading of documents using dummy examples of payment instructions.

• Security settings check

  Check user access rights and encryption parameters when transmitting data through integration channels.

Algorithm for discrepancy control and verification of accounting entries

Automation of payment reconciliation is based on comparing data obtained from different sources according to defined criteria. Reconciliation rules should include checking for the existence of accounting entries for documents marked as posted. This ensures that every operation reflected in the statement has a corresponding entry in the accounting accounts. However, the technological status of a payment obtained through the "TrackSEP" service is not a basis for automatic posting and requires confirmation by financial documents.

In case of discrepancies between statement data and the accounting system, for example, a mismatch in the amount or counterparty details, the operation should not be processed automatically. The system must block automatic matching and pass the document to a responsible operator for manual review. This prevents erroneous crediting of funds or distortion of reporting. It is recommended to develop clear instructions for operators on actions to take in case of such discrepancies, detailing the reconciliation procedure for hypothetical scenarios, which will help standardize the process of resolving disputes.

FAQ

Sources

• bank.gov.ua
• treasury.gov.ua
• a5erp.solutions
• iqusion.com
• bank.gov.ua