Learn how to import bank statements into 1C 8.3 via bank-client or direct exchange, allocate payments, and handle unidentified transactions.
A bank statement can be uploaded to 1C in a minute through direct bank exchange or a file from the client bank. The real work starts afterward: matching each payment to a counterparty, contract, and document. It is allocation, not uploading, that consumes time and creates discrepancies later revealed during reconciliation and month-end closing.
Statements are located in the "Bank and Cash" → "Bank Statements" section. Both upload methods are available there.
1C retrieves the statement from the bank automatically, either on schedule or at the click of a button. It is configured once in the bank account card; the bank must support this type of exchange. No files are needed, and the manual step disappears.
The classic approach: export an exchange file from the bank-client system and upload it to 1C. It works with any bank, but remains a manual task that someone must perform every day.
An important distinction: automatic uploading only eliminates the step of obtaining the file. It does not allocate payments; the lines still need to be matched with contracts and documents.
Each line becomes a receipt to or payment from the bank account.
Customer payment, supplier payment, tax, payroll, other receipt or write-off. The transaction type determines the accounting accounts and analysis dimensions.
Using the Tax ID and bank account from the payment order. A new counterparty requires creating a record and checking its details.
A key step. With one contract, it is filled in automatically; with several, it is selected based on the payment purpose or manually.
The payment is linked to an invoice or shipping document, or remains an advance. This affects both reconciliation and VAT on the advance.
After verification, the entries are posted; unverified ones remain in the statement and can easily be lost among different days.
Selection by Tax ID and amount covers the standard workflow. Problems arise when the payment order simply lacks sufficient data.
Part of the invoice amount has been received. You need to decide which document to assign it to and whether to leave the remainder as an outstanding debt. Automation cannot find an exact match here.
A counterparty paid three invoices with one payment. The payment must be split; otherwise, two invoices will remain outstanding and the third will show an overpayment.
One company pays, while another holds the obligation. The Tax ID identifies the wrong counterparty; a supporting letter and a manual decision are required.
"Contract payment," "for services," "account top-up." There is no way to identify the contract if the counterparty has several.
A refund from a supplier, an advance offset, or a transfer between your own accounts. Formally, these are receipts, but they are accounted for differently.
All five cases have one thing in common: they cannot be resolved by the rule "amount equals amount." Context is required—a contract, relationship history with the counterparty, an email, or a manager's agreement. As a result, these payments accumulate at the end of the day and are processed in batches, while some are never reviewed at all.
An unposted or incorrectly posted payment does not prevent work today.
The invoice exists in the database, the money has arrived, and the stock report reconciles.
It appears later and elsewhere: - during reconciliation with the counterparty - the contract balance does not match because the payment was posted to another contract with the same counterparty; - in accounts receivable - the invoice is shown as unpaid, so the manager reminds the client about a debt that has already been settled; - at month-end closing - an advance payment that should have been offset is discovered, along with VAT on the advance; - in the payment calendar - the forecast is based on incorrect contract balances.
This leads to a practical rule: posting is not a technical operation, but the point where the quality of all subsequent reporting is determined.
See the articles for more details about the consequences "Month-end closing errors in 1C" and "Payment calendar in 1C". ###
What this costs the company. A section for managers whose accountants share this material with them. The statement process looks deceptively simple: “import and allocate.”
Its cost is hidden in two places.
First: daily processing:
Second, there is a backlog of disputed payments that does not shrink with experience because it depends on how counterparties pay, not on the accountant's expertise. Questions worth asking the team: -
How many payments pass through the accounting area each day, and how many are not posted automatically? -
Who processes the statement when that person is on vacation? -
How often does reconciliation reveal a payment allocated to the wrong contract?
The useful task to automate here is not uploading—the 1C system already handles that—but verified allocation: the agent matches each payment to a contract and document according to company rules, while partial, unidentified, and disputed payments are placed in a separate queue with the reason specified.
This is one of the processes AI accountant; alongside them are source document recognition and reconciliation statement automation, where incorrect allocation becomes apparent.
FAQ
In the "Bank and Cash" → "Bank Statements" section. Each statement line becomes a document for a receipt to or payment from the bank account.
It eliminates the manual step of retrieving and uploading the file: 1C fetches the statement itself. This does not affect payment posting; matching with contracts and documents remains unchanged.
Usually, the payment details contain no invoice or contract number, the counterparty has several of them, or the amount does not match exactly because of a partial payment. Automatic matching relies on an unambiguous match.
Supporting documentation is required: a letter confirming payment for another organization. The payer’s Tax ID will identify the wrong counterparty, so the payment is posted manually against the debtor’s obligation with a reference to the letter.
The payment is allocated to the underlying documents within the receipt document itself. If this is not done, some invoices will remain unpaid and one of them will show an overpayment.
Yes, but the "amount-to-amount" rule is not enough: context is needed—contracts, payment history, emails, and agreements. The agent applies company rules and sends disputed payments to an exceptions queue instead of guessing.
No. The connection to the existing database is made through OData; the available documents and directories, as well as the operations the agent may perform, are agreed in advance.
