Automated reconciliation with 1C, bank and EDI
The agent matches bank statement lines against 1C postings, assembles the reconciliation act over EDI and catches duplicate payments.
Scenarios for this job
Every scenario is a ready brief for the agent: the steps, the connected systems and the output. Open one and run it on your own data.
The agent reconciles the Tochka statement against 1C entries for the period, finds mismatches by amount and counterparty, and shows which entries are missing.
The agent assembles the quarterly reconciliation statement from 1C and EDI data, matches documents on both sides and prepares the file to send to the counterparty.
The agent scans the month's payments across the bank and 1C, finds doubled payments, stray charges and subscriptions everyone forgot about.
The agent checks an incoming invoice: counterparty details, match against the contract and amount, duplicates — and says whether it's safe to pay.
The agent assembles the reconciliation act in SBIS for a counterparty, matches it against settlements in 1C and shows the lines where the two sides disagree.
Reconciliation is matching work: the same operation has to look the same in two places. The bank statement against postings in 1C, your reconciliation act against what the counterparty sees, an incoming invoice against the contract and against what was already paid. At a hundred operations the human eye copes. At a thousand lines a month it stops seeing exactly what the reconciliation exists for — the payment that went out twice, the transfer to the wrong counterparty, the document the counterparty signed that was never posted on your side.
The classic method is to export the statement from Tochka and the turnover sheet from 1C into Excel and match on amount and date. It breaks on details: a bank fee separates the payment from the invoice amount, one payment closes three delivery notes, the same counterparty is spelled differently in two systems, the payment purpose is free text. After that it is done by eye. At quarter end you also mail out reconciliation acts and wait for them to come back with corrections — and until late January nobody knows whether the year adds up.
The agent does the matching itself. It pulls operations from the bank — Tochka, T-Bank, Modulbank, SberBusiness, Alfa-Bank — postings and settlements from 1C over OData, and documents from Diadoc and SBIS, then matches on counterparty, amount, date and payment purpose while tolerating inexact hits: partial payments, merged transfers, different spellings of one name. The output is a list of discrepancies with a reason attached to each: no document, payment duplicated, amount off by the bank fee, invoice paid but never closed by an act. The quarterly reconciliation act comes out as a file ready to send. Posting, accruals and signatures stay with a person: the agent changes nothing in 1C or in the bank.
Common questions
How does it match a payment when the amounts differ?
On a combination of signals: counterparty, date, payment purpose and any invoice number inside its text. Partial payments, one transfer covering several delivery notes and gaps equal to the bank fee are handled separately and marked as probable matches rather than discrepancies.
Which banks can be connected for reconciliation?
Tochka, T-Bank Business, SberBusiness, Modulbank and Alfa-Bank Business — statements and operations are read through the bank API. If your bank is not on the list, the agent takes an export in 1C format or a spreadsheet and applies the same rules.
Will the agent fix the discrepancies in 1C?
No. It hands over the list of discrepancies with a reason and an amount and suggests what to do with each one. Posting, accruals and corrections stay with the accountant, because access to the database is granted read-only.
Can we reconcile weekly instead of at quarter end?
Yes, any reconciliation can run on a schedule. A daily check of the statement against 1C catches a duplicate payment the same day rather than two months later, and by the quarterly close far fewer lines are left in dispute.