Importing and validating bank statements in 1C
We developed an import tool for statements from three banks in 1C:Accounting for Kazakhstan. Transactions are checked for counterparties, contracts and duplicates, and payment documents are saved without posting. Technical tests are complete; accountant acceptance testing on a database copy is next.
A statement already contains payment details, but working with them in 1C means finding the counterparty, selecting a contract and avoiding duplicate imports. With several banks, the accountant repeats this work across differently structured files.
For 1C:Accounting for Kazakhstan, edition 3.0, we developed a statement import tool with a separate review stage. Its purpose is to prepare data for accountants, not to make accounting decisions for them. Version 1.0.14.1 has passed technical tests and is ready for acceptance testing on a copy of the working database; production deployment has not yet been confirmed.
Review transactions first, create documents second
The process starts by selecting the organisation and its bank account. The accountant imports a single statement, and its transactions appear in one table: date, payment direction, details, contract, payment purpose and validation messages. A successfully read file does not mean that every row is ready to be saved.
Support has been confirmed for the supplied Excel files from Bereke Bank, ForteBank and Bank CenterCredit, in XLS and XLSX formats. For each payment, the accountant can check the suggested values, correct them or deselect the row from the import. Corrected rows are checked again. Any payment document created can be opened directly from the results and compared with the original.
Distinguishing similar counterparties and payments
Counterparties are matched by their exact Business Identification Number (BIN) or Individual Identification Number (IIN), not by a similar name. If there is no matching record, or several matches are found, the decision stays with the accountant. The tool does not create new records on its own. Contracts are checked in the same way: they must belong to the correct counterparty and organisation. An arbitrary selection must not conceal an ambiguous match.
Rules handle recurring payments. For example, the accountant can link the payment direction and a recurring phrase in the payment purpose to an operation type and a cash flow item—the category used to classify the payment in cash flow reports. There are nine standard scenarios, including supplier payments, taxes and transfers between the organisation's own accounts. Cash flow items are selected from the company's database.
Manual selections are retained when validation is repeated. If two rules with the same priority apply, automatic allocation is blocked until the ambiguity is resolved. Both duplicate transactions and duplicate files are checked.
Why documents are saved without posting
An incoming payment order is prepared for a receipt, and an outgoing payment order for an expense. Only new documents are created; existing ones are not overwritten. Before saving, the server checks the selected rows again so that it does not rely on an outdated preliminary validation result.
An unposted document is a saved draft in the database that has not yet generated accounting entries. The Paid flag also remains off. The accountant opens the draft, checks its details and decides when to post it using the standard 1C command. Saving still changes the database and allocates document numbers, so initial tests are performed on a copy.
What the tests showed
- The Bereke Bank XLS file yielded 30 transactions, the ForteBank XLSX file 3, and the Bank CenterCredit XLS file 6. All these rows were left for manual review: this is a file-reading result, not 39 automatically accepted payments.
- A separate test confirmed that an incoming document was saved without posting, without the Paid flag and without register entries.
- Duplicate rows and files were detected before they could be saved again. Saving rules and handling empty, damaged and unrecognised files were also tested.
Where the solution's limits lie
Support for three banks does not mean compatibility with every bank template. A new format needs a sample and a separate test. PDF text-layer parsing has been prepared, but server-side text extraction did not work on the tested platform. PDF import therefore cannot yet be treated as a working feature: a suitable server component and further tests are needed. Scans also require prior optical character recognition (OCR).
The tool can be supplied in one of two forms: a CFE extension, which adds functionality as a plug-in module, or an EPF external processing tool, which is opened separately in 1C. The main configuration is not directly rewritten, and there is no need to install both versions at once. Permissions, compatibility and cloud service conditions are checked during implementation.
Next step: acceptance testing on real tasks
The practical outcome is a single place to read statements, review uncertain details and prepare payment documents. Time savings in day-to-day use have not yet been measured. Before going live, the accountant needs to approve the rules, check real statements on a database copy and review one unposted document under a regular user account.
If your accounting team repeatedly re-enters bank transactions by hand, discuss the task with JEL Studio. We will review your statement formats, database limitations and checking procedure to propose a customisation for your specific process, rather than promise to automate everything.