1C Integration with Your Bank and Statement Import
We set up bank statement import into 1C so the accountant does not post payments by hand: counterparties and contracts are matched automatically, and unrecognized payments are collected in a separate list. We work with Kazakhstan banks and several accounts at once.
- We fix "1C will not import the statement" and format errors
- Counterparty matching rules by BIN, IIN and payment purpose
- Scheduled statement import from a folder or via the bank's API
- Several banks and accounts in one database without confusion
1C bank integration starts at 350,000 tenge. Setting up statement import takes one to two weeks, and scheduled auto-import two to three weeks.
Why integrate 1C with your bank
Manual statement posting eats hours and produces errors.
In a company with hundreds of payments a day, the accountant spends several hours on statements: download the file from online banking, load it into 1C, find the counterparty and contract for every receipt, post the payment against invoices. An error in one payment becomes a wrong customer balance and a call demanding payment for something already paid.
1C bank integration removes the manual part. The statement loads itself, payments from known counterparties are posted by rules, and a person is left with only the genuinely unclear operations: new payers, payments without an invoice reference, refunds. In practice this is usually a small share of the total flow, and reviewing it is much faster than the whole list.
Another benefit is cleaner data. For automatic posting to work, counterparties need their BIN and bank accounts filled in. The integration also exposes cards with empty details and duplicates that were getting in the way before, just unnoticed.
Sales benefit too: a manager sees the client's payment in 1C the same day, not after the accountant gets to the statement. Shipments on prepayment stop waiting.
How 1C bank exchange works
Three approaches, from simple to fully automatic.
| Approach | How it works | When it fits |
|---|---|---|
| File from online banking | The accountant downloads the statement in 1C format and loads it with a data processor | Few payments, one bank |
| Auto-import from a folder | Statement files land in a folder and a 1C scheduled job picks them up on a schedule | Several accounts, a daily flow |
| Bank API exchange | 1C requests the statement from the bank over a secure channel | If the bank offers an API for corporate clients |
The standard bank exchange format in 1C is the 1CClientBankExchange text file. Most banks in Kazakhstan can export statements in it, but each bank fills in the fields its own way: some put the payer's BIN in a separate field, some only in the payment purpose, some use a different encoding. That is where most import problems come from.
Trading companies have one more source: payment registers from payment systems and aggregators. This is not a bank statement, but it is posted in a similar way, and it is convenient to load it with the same data processor so all receipts are in one place.
We choose the approach after a review: which banks, what payment volume and what your bank offers corporate clients.
Kazakhstan banks in 1C
We work with the banks where you hold accounts.
Most often we set up statement import for Kaspi, Halyk Bank, Freedom Bank, Bank CenterCredit (BCC), Jusan and ForteBank. One database often has three or four banks and a dozen accounts, including foreign currency ones. For each bank we check how it builds the statement file and configure the import so one bank's quirks do not break posting for another.
A separate topic is receipts through Kaspi Pay and card acquiring. Money arrives as one sum per day, net of commission, while accounting needs to see individual sales. Here the bank statement is matched against the payment register, and the difference is split into commission and refunds. If you sell on the marketplace, this is often solved together with 1C Kaspi integration.
If the company has several legal entities in one database, each account is linked to its own organization, so a statement never lands in the wrong one. This is a common error in manual import, when the accountant picks the organization from memory.
Foreign currency accounts need their own rules: exchange differences, conversion, the bank's currency control fee. These operations can be posted automatically too once the rules are described.
Why 1C will not import a bank statement
Common causes and what to do about them.
"1C will not import the bank statement" is the request we hear most. The causes are usually the same.
- File encoding. The bank produced the file in one encoding, 1C expects another, and counterparty names turn into unreadable characters.
- Account number mismatch. The IIC (account number) in the statement has spaces or a different format than in the organization's bank account card.
- The bank changed its format. The bank updated its online banking, a field moved, and an import that worked for years stopped finding the data.
- Repeated import. The statement was loaded twice and duplicate payments appeared.
- Counterparty not found. The payment loaded without a counterparty because the BIN on the card is empty or wrong.
There are less obvious causes too: the statement loads into a different organization in the database because two legal entities have similar accounts; the statement date falls into a closed period; the user lacks rights to create payment documents. Each of these is diagnosed in minutes if you know where to look.
A one-off import problem is fixed in a few days. If it recurs with every change on the bank's side, a custom import data processor that withstands such changes makes sense.
Statement posting and counterparty matching
The heart of the integration is not loading but rules.
Loading statement lines into 1C is easy. Posting each one correctly is hard: finding the counterparty, contract and invoice, deciding whether it is a payment, an advance or a refund. We describe posting rules together with your accountant and turn them into code.
- Counterparty by BIN or IIN. The most reliable key. If the BIN on a card is empty, we show which counterparties need completing.
- Contract and invoice by payment purpose. We look for the invoice or contract number in the payment purpose using the patterns your clients use.
- Operation type. Customer payment, supplier payment, taxes, payroll, bank fee: each type is posted with its own document.
- Unidentified payments. Collected in a separate list with hints about who may have paid: an amount matching an open invoice, a similar name, past payments from the same account.
- Rule learning. When the accountant manually posts a new payment type, a rule can be added so next time it posts itself.
Scheduled statement auto-import
So statements appear in 1C with no human involvement.
A 1C scheduled job picks up new statement files from the exchange folder once an hour or once a day, or requests them from the bank, then loads them, posts them by the rules and writes a log. In the morning the accountant sees the loaded statements and a short list of what needs attention.
The schedule fits the company's rhythm: for retail with card acquiring, once a day after the banking day closes is enough; for a wholesaler working on prepayment, once an hour is better so the warehouse can ship as soon as the money arrives.
An important detail is protection against repeated import. The job remembers which statements have been loaded and does not create duplicates even if a file lands in the folder twice. Another detail is alerts. If the day's statement did not arrive or contains an error, the person in charge gets a Telegram message instead of finding out at month end.
How to set up such jobs and what else is worth handing to a schedule is covered in 1C scheduled jobs (in Russian).
Payment orders from 1C to the bank
The exchange works both ways.
Besides importing statements, 1C can export payment orders to the bank. The accountant creates payment orders in 1C, exports them as a file and uploads them to online banking, where they are signed with a digital signature. This eliminates retyping details and errors in the recipient's account number.
For companies with many supplier payments we set up batch export: a payment register goes to the director for approval, and after approval it is exported as a single file. Signing and sending remain in online banking under the control of the authorized person: we do not store keys or send payments on your behalf.
If it is more convenient to approve the register on a phone, a mobile app or bot solves it. Such tasks are handled by the Telegram bot for 1C on applications.kz.
How the work goes
From review to working auto-import.
- Review. We look at the configuration, banks, accounts, a month of sample statements and the current posting process.
- Posting rules. Together with the accountant we describe how each payment type is posted.
- Development on a copy. We set up the import and rules on a copy of the database.
- Testing on real statements. We load last month's statements and compare the result with how the accountant posted them.
- Move to the live database. We switch on the import and, if needed, the schedule.
- Two weeks of observation. We refine the rules on new payment types.
Launch usually takes less time than agreeing the rules. So at the start we ask you to assign an accountant who knows how complex payments are posted today and can decide disputed cases.
The customization is an extension or an external data processor; the standard configuration does not change and updates normally. More about this approach on the 1C customization page.
Timelines and cost
Depends on the number of banks and the complexity of the rules.
| Task | Timeline | Price |
|---|---|---|
| Fix statement import for one bank | 2-5 days | from 150,000 ₸ |
| Import and posting with rules, one or two banks | 1-2 weeks | from 350,000 ₸ |
| Scheduled auto-import with alerts | 2-3 weeks | by estimate |
| Several banks, foreign currency accounts, acquiring | from 3 weeks | by estimate |
At the end: working statement import, a description of posting rules, a guide for the accountant and the data processor source code. If the bank changes its format, the fix is done under 1C support or as a one-off task.
For those who want to figure it out themselves, we published a step-by-step guide: importing bank statements into 1C in Kazakhstan (in Russian).
How we differ, and who this is for
For companies where statements take hours to post.
A franchise partner usually sets up the standard file import and stops there: posting rules for your clients and scheduled auto-import are customization, not configuration. A freelancer can write a data processor, but without monitoring it quietly stops working at the bank's first format change.
Another difference: we build 1C integrations with websites, Kaspi and apps ourselves, so bank payments can be linked straight to online store orders and CRM statuses. The buyer gets a payment notification, and the manager sees it on the order card without calling accounting.
We build the import with rules, test it on real statements and watch it after launch. Integration pays off best in trading and service companies with a large flow of customer payments, companies with several banks and legal entities, and distributors with payments through acquiring and marketplaces. If you need a different 1C task, start with the 1C developer page.
FAQ about 1C bank integration
Formats, banks and automation.
How much does 1C bank integration cost?
From 350,000 ₸ for statement import and posting for one or two banks, 1-2 weeks. Fixing import for one bank starts at 150,000 ₸. Auto-import and several banks are estimated after a review.
Which banks do you work with?
Kazakhstan banks where you hold accounts: Kaspi, Halyk, Freedom, BCC, Jusan, ForteBank and others. We check each bank's statement format on your samples before promising automation.
Why will 1C not import the bank statement?
Most often because of file encoding, a different account number format, changes on the bank's side or an empty BIN on the counterparty. We find and fix a one-off problem in a few days, and if it recurs we build a custom import data processor that withstands bank changes.
Can statements be imported automatically?
Yes. A scheduled job picks up files from a folder or requests the statement through the bank's API, if the bank provides one, and posts payments by the rules. A repeated import does not create duplicates.
Do you get access to our money?
No. We work with statements and payment order files. The digital signature and sending of payments remain in online banking with the responsible employee. We neither store nor request the company's signature keys.
What happens to payments that are not recognized?
They go into a separate list with hints about the possible payer. The accountant posts them manually, and a new rule can be saved for the future. Over time the list of unidentified payments gets noticeably shorter.
Will the standard configuration change?
No. We build the import and rules as an extension or external data processor, so the database stays on vendor support and updates normally. The data processor source code is handed over with a guide.
Do you work with foreign currency accounts?
Yes. For currency operations we describe separate rules: conversion, exchange differences, bank fees. These can be posted automatically too, once the rules are described together with the accountant using examples of past operations.
More 1C services
Related tasks that usually go together.
1C developer
1C tasks with an estimate before work starts.
External 1C data processors
Imports and bulk operations without editing the standard configuration.
1C Kaspi integration
Marketplace orders and payments into accounting.
1C support
We make sure exchanges and imports keep working.
AI and automation for 1C
Telegram notifications and document recognition.
Send a request
Describe the task: we reply within one business day and quote before any work starts.