Federal Treasury statements into 1C: 5 seconds per statement, down from 2–3 hours
Every week an accountant at a government-contract company converted XML statements from the Federal Treasury's GIS system into the 1C format by hand. I wrote a Python converter that reads both versions of the format, and now a statement is converted in a single run.
Hours of picking through XML by hand, every month
Every week an accountant at a government-contract company received XML statements from the Federal Treasury's "Electronic Budget" system. Each statement is an XML document with dozens of nested tags: recipient details, the Treasury office (ORFK) and the legal entity, credit and debit amounts, and balance items for each personal account.
To load this data into 1C, it had to be moved into the
1CClientBankExchange
format. This is the text format 1C uses to exchange data with bank-client software. It is
encoded in Windows-1251, has a strict structure of
SectionDocument=...
sections and dozens of required fields for every payment.
In practice this meant opening the XML in an editor and copying each field by hand into the
Excel mapping table
Payment_Treasury_1C_mapping.xlsx.
Then came checking the counterparties, checking the amounts against the control figures,
converting to the right encoding and saving the file. And the same again for every payment
in the statement.
Python reads both versions of the format, and 1C loads the result directly
The design is simple and the data flows one way, so there is very little to break. A single command-line script reads the XML file, detects the format version, pulls out the fields it needs, maps them through the table and writes a finished 1CClientBankExchange file in the right encoding.
A file from the Treasury GIS: V3 (TSE_BalanAcc_D13) or V4 (TSE_BalanAcc2_D13)
xml.etree.ElementTree; the version is detected automatically from the root element's namespace
BasicRequisites, ORFK, LegalEntity, balance_items → 1C fields
1CClientBankExchange template, Windows-1251 encoding
The file loads through 1C's standard bank-client exchange
Two XML versions, one result
The Treasury GIS uses two statement formats at the same time: V3
(TSE_BalanAcc_D13)
and V4
(TSE_BalanAcc2_D13).
Their fields and namespaces differ. The script detects the version from the root element and
picks the matching way to read it. Either way, the output is the same data structure.
The script pulls out every field that matters
The script extracts the statement header, every payment and the balance items, and checks the control sums along the way:
BasicRequisites: document details, period, statement numberORFK: the Federal Treasury officeLegalEntity: the legal entity, its INN/KPP tax registration codes, the personal accountSDTotalSum/EDTotalSum: debit and credit control sumsbalance_items: each balance item broken down by KBK, the budget classification code
Windows-1251 encoding without surprises
The 1CClientBankExchange format expects Windows-1251. The converter opens the output file
with
encoding="cp1251"
and handles in advance any characters that this encoding can't represent. So the import into
1C comes out without garbled text.
Simple technology, chosen on purpose
One script, no cloud services needed
Part of the standard library, no extra packages
The encoding that 1CClientBankExchange requires
The bank-client exchange standard: 1C loads the file with its built-in tools
Payment_Treasury_1C_mapping.xlsx, the field reference
Runs from the command line or from a .bat file on the accountant's computer
Before and after, side by side
per statement
amounts come straight from the XML, and the control sums are checked before the file is written
both versions of the Treasury GIS XML statement
The main result: a whole class of manual-entry errors disappeared. Every field comes straight from the source XML, and nobody retypes amounts from the screen any more.
The accountant double-clicks a .bat file and gets a file ready to load. The checking now happens in 1C, where it belongs.
The same statements can also be converted right in the browser with my free online Treasury-to-1C converter (the page is in Russian).
Where else the same approach works
Behind this case is a common task: "turn a document in one strict format into another, using a fixed mapping table". The same design works anywhere data has to move from one system to another without manual entry:
- → Bank statements in the 1C bank-client or SUFD format: the same fields, a different namespace
- → UPD and e-invoicing documents from Kontur.Diadoc or SBIS → import into 1C: Trade Management or 1C: Accounting
- → "Honest Sign" product marking: XML reports into the accounting system
- → Tax returns and reports in non-standard Federal Tax Service formats → internal spreadsheets
- → Tender documents (XML exports from government procurement portals) → a CRM or internal Excel registers
- A script template that detects the format version from the root element
- The field mapping lives in an Excel reference table that the accountant edits without touching the code
- Control sums are checked before the file is written: if they disagree, the script stops and the error stays out of the books
- A .bat file on the accountant's computer, so nobody has to deal with Python
A document arrives in one strict format and you need it in another? That can be automated
A document converter is predictable automation: the input and the output are known in advance. From the first XML to live use takes 3–7 business days, and the payback is easy to work out on the back of an envelope.
Blog article on this topic: A Telegram bot for 1C without the 1C client: where a data exchange needs no language model
Related cases
Forecasting events with several language models: calibration and Brier scoring
Five AI agents search open sources, a sixth reconciles their answers, and a calibration step adjusts the…
Language models analyze trading signals right on a laptop: Ollama and RAG on an M3
qwen2.5:14b is the main model, llama3.1:8b the backup, and LLaVA:7b reads chart screenshots; ChromaDB finds…
A sales-figures bot: six metrics, with the arithmetic checked by AI agents
A Telegram bot reports sales by country, year, product and US state through one shared metrics core. All the…
Start with the 5,000 ₽ audit: a written report and a payback estimate
I'll tell you what to automate first, when it will pay for itself and whether your task needs AI at all. Sometimes it doesn't.
Or just ask a question. During business hours I reply within 2 hours