Integrating 1C with Banks and Payment Systems in Uzbekistan: Client-Bank, Statements, Payme and Click

Why manual payment entry stops scaling

While only a dozen operations pass through your current account each month, an accountant can comfortably key them into 1C by hand. But the moment a business starts accepting retail payments via Payme and Click, and legal entities send payment orders in batches, manual entry becomes a source of errors and reconciliation gaps. A payment has arrived but is not yet in 1C; money is credited but not linked to the right counterparty; the same statement is imported twice. For a company in Uzbekistan this is not abstract: discrepancies on the current account surface during reconciliations, when preparing ESF (electronic invoices) and during tax reporting.

Integrating 1C with the bank and payment systems solves three problems at once: it pulls bank statements automatically, matches incoming funds to contracts and counterparties correctly, and brings online payments from individuals into a single accounting loop. Let us look at how this works in the realities of the Uzbek market.

Client-Bank: the classic 1C-to-bank link

Most Uzbek banks provide legal entities with internet banking ("Bank-Client", "Business Online" type systems) that export and import payment documents. The most basic and reliable integration channel is exchange via the text file format 1CClientBankExchange. 1C generates payment orders and exports them to a file, the accountant uploads it into the client-bank and signs it with a digital signature; the bank, in turn, returns the statement in the same format, and 1C posts it automatically.

This scenario does not require a permanent internet connection between 1C and the bank and works with virtually any bank supporting the 1C format. Its downside is that it still involves a manual step: someone must download the statement file and import it into the database. For companies with high payment volumes the logical next step is direct exchange via the bank's API.

Statements: automatic import and reconciliation

The bank statement is the primary document for posting money. During integration it is important not only to load the statement lines but also to exclude duplicates and match operations correctly. A properly configured exchange checks each line against the bank's unique operation identifier, date and amount, and does not create duplicate documents if the day's statement was imported twice.

A distinct nuance of the Uzbek market is working with two currencies and with conversion. Receipts in dollars or euros, mandatory sale of part of foreign currency revenue, exchange rate differences — all of this must be reflected correctly when the statement is loaded, otherwise foreign currency account balances drift. That is why foreign currency accounts are always tested separately from soum accounts.

Payment matching: linking money to a counterparty

A loaded statement by itself is just a list of credits and debits. The value of integration lies in automatically linking each amount to a counterparty and contract. Several mechanisms work here: matching by the payer's tax ID (INN), by current account, by the payment purpose text (invoice or contract number), and by the expected receipt amount.

In practice, well-configured matching closes 80-95% of receipts automatically, while the accountant reviews the remaining disputed lines manually. To keep the automation rate high, it is important to train counterparties to state the invoice or contract number in the payment purpose, and in 1C to keep the counterparty directory in order (filled-in INNs and bank details). Without clean directories any automation stalls.

• By INN and current account — the most reliable indicator for legal entities.
• By invoice/contract number in the payment purpose — closes most B2B payments.
• By amount and expected receipt — helps when the payment purpose is empty or generic.

Payme and Click: bringing online payments into the accounting loop

Payme and Click are the two dominant payment services for accepting payments from individuals in Uzbekistan. If a company sells services or goods to retail customers (subscriptions, orders, an online storefront), money from thousands of small payments arrives not via a classic payment order but through the payment system's API. These receipts must also be visible in 1C — otherwise the revenue in the books will not match what sits in the merchant account.

It is important to understand the mechanics here: Payme and Click operate on a model where a payment is first authorized (transaction creation) and then confirmed (capture). Money reaches the current account not one by one but as a register for a period — net of the service commission. So the integration must solve two separate tasks: record each online payment as a sale/receipt event, and at the same time correctly reconcile the aggregated payment from the payment system (a daily or weekly settlement) with the bank statement.

Payment automation: what to aim for

Mature payment automation in 1C looks like this: outgoing payment orders are generated in 1C (for suppliers, payroll, taxes) and sent to the client-bank for signing; incoming statements are imported and matched automatically; online payments from Payme and Click are pulled on a schedule and create sale and receipt documents on their own; ESF on Didox is generated from accounting data without double entry. The accountant no longer keys in lines but supervises exceptions.

There is no need to implement everything at once. A sensible sequence is: first set up reliable statement import and counterparty matching, then connect outgoing payment orders, and only afterwards integrate Payme/Click and link to ESF. Each stage delivers measurable time savings and reduces errors before you move on to the next.