1. Identification
| Parameter | Value |
|---|---|
| Object Type | Document (Document.ESF) |
| Name | ESF |
| Synonym | “Electronic Invoice” |
| Configuration | Accounting for Kazakhstan, edition 3.0, version 3.0.74.2 |
| Country/Specificity | Republic of Kazakhstan, integration with the ESF Information System (electronic invoices) |
| Navigation Link | e1cib/list/Document.ESF |
| Where to find in 1C | Section “Sales” → “Electronic Invoice”. For incoming invoices, the list form IncomingListForm is used, for outgoing invoices — OutgoingListForm |
Purpose. The document ESF is a key accounting object for working with electronic invoices in Kazakhstan. It facilitates the formation, sending, receiving, and processing of ESFs in accordance with the requirements of the tax legislation of the RK and integration with the ESF Information System. The document is used by accountants and chief accountants daily: during the sale of goods/services (outgoing ESFs) and when accounting for received goods/services (incoming ESFs).
The document can be created:
- manually;
- automatically based on the “Invoice” document;
- by uploading from an XML file;
- by synchronization (receiving) from the ESF Information System.
Important.
ESFis a tax electronic document flow, not a sales document. The fact of sale, income recognition, and VAT are reflected in the documents “Sale of Goods and Services” and “Invoice”.ESFserves for exchanging the electronic form of the invoice with the state system ESF. From 2026, the VAT rate in the RK is 16% — this is the rate indicated in the related invoice and transferred to the ESF.
2. Header Attributes and Table Parts
Header Attributes
According to evidence, mandatory header attributes (without them, the document cannot be processed):
| Attribute | Purpose |
|---|---|
| Direction | Defines the type of document flow: outgoing (sale) or incoming (purchase) ESF |
| TransactionDate | Date of the transaction (sale/purchase) — basis for the tax period and VAT reporting |
| Type | Type of ESF: main, additional, corrected. Defines the logic of exchange and connection with the original document |
| CurrencyCode | Currency code of the document. For domestic operations in the RK — tenge (₸). For foreign currency operations, the exchange rate to tenge is indicated |
| Warehouse | Virtual warehouse from which the movements of goods are formed (see section 5) |
Additionally, the header typically includes: organization, counterparty (supplier/recipient), number and date, reference to the underlying document (invoice), ESF status, registration number in the ESF Information System, contract details, and turnover signs (taxable/exempt from VAT).
Table Parts
| Table Part | Mandatory Columns | Purpose |
|---|---|---|
| Suppliers | SupplierIdentifier |
Data about suppliers (for incoming ESFs and resale chains) — identification of the transaction participant |
| Goods | GoodsName |
ESF nomenclature: name, quantity, price, amounts excluding VAT, VAT rate and amount (16%), total amount including VAT, HS code, goods origin indicator, number by “Virtual Warehouse” |
| GoodsBySuppliers | Identifier |
Distribution of goods by specific suppliers (accounting for batches/origin for traceability purposes) |
| GoodsByRecipients | Identifier |
Distribution of goods by recipients (for outgoing ESFs and multi-position operations) |
| Typical Errors (service) | Text, Field |
Storage of validation errors of the ESF during exchange with the ESF Information System or internal checks |
Service table part “Typical Errors”:
| Column Name | Type | Purpose |
|---|---|---|
| Text | xs:string | Text of the error message |
| Field | xs:string | Name of the field where the error was detected |
If a mandatory field is not filled, 1C will not allow the document to be processed and will issue an error of the type “Field … is not filled”.
3. Forms
| Form | Purpose |
|---|---|
| IncomingListForm | List of incoming ESFs (received from suppliers and from the ESF Information System). Here, acceptance, registration, and rejection of incoming documents are performed |
| OutgoingListForm | List of outgoing ESFs (issued during sales). Here, sending to the ESF Information System, revocation, and creation of corrective ESFs are performed |
| Document Form (standard) | Main form for editing header attributes and table parts, sending/uploading ESFs, viewing status and errors |
| Selection Form (standard) | Selecting ESFs when linking to related documents |
4. Key Module Procedures
The attached evidence does not contain BSL fragments with paths and line numbers, therefore below are listed the typical handlers of documents of this type. Specific procedure names should be clarified according to the object module of the corresponding version.
Object Module (ProcessingConducting, ProcessingValidation, BeforeSaving):
ProcessingValidation— checking mandatory attributes (Direction, TransactionDate, Type, CurrencyCode, Warehouse) and mandatory columns of table parts; filling the service table part “Typical Errors”.ProcessingConducting— generating movements in the virtual warehouse registers (see section 5).BeforeSaving/OnSaving— assigning a number, fixing the ESF status, preparing data for exchange.
Form Module (document form and list forms):
- handlers for sending ESFs to the ESF Information System and receiving receipts/statuses;
- handlers for uploading from an XML file and parsing the structure of the ESF;
- handlers for rejecting incoming and revoking outgoing ESFs;
- handlers for creating corrective/corrected ESFs based on the original.
Common Modules (integration with the ESF Information System):
- digital signature, forming a package for sending, parsing responses from the ESF Information System, updating statuses, maintaining an error log.
5. Processing and Movements
The document ESF does NOT generate accounting entries (Dr/Cr). This is a fundamental feature of the object: ESF reflects tax electronic document flow, not financial results.
When processed, the document generates movements only in accumulation registers:
| Accumulation Register | Purpose |
|---|---|
| GoodsInVirtualWarehouses | Accounting for goods balances in virtual warehouses (module “Virtual Warehouse” of the ESF Information System / traceability) |
| GoodsInVirtualWarehouseReserve | Accounting for goods reserved in the virtual warehouse |
Where Accounting Entries and VAT are Formed
Financial accounting and VAT for the transaction are reflected in related documents (standard chart of accounts of the RK):
| Operation | Entry | Comment |
|---|---|---|
| Sale of goods (income) | Dr 1210 “Short-term Receivables from Customers” – Cr 6010 “Income from Sales” | Forms “Sale of Goods and Services” |
| Accrual of VAT on sales (16%) | Dr 1210 – Cr 3130 “VAT Payable” | VAT rate in RK 2026 — 16% |
| Cost of goods sold | Dr 7010 “Cost of Sales” – Cr 1330 “Goods” | Forms “Sale of Goods and Services” |
| Receipt of goods | Dr 1330 – Cr 3310 “Payables to Suppliers” | Forms “Receipt of Goods and Services” |
| VAT offset on purchase (16%) | Dr 1420/3130 – Cr 3310 | According to the incoming invoice |
| Payment | Dr 1030 “Cash in Current Accounts” – Cr 1210 / Dr 3310 – Cr 1030 | Forms payment documents |
Example for VAT: a sale of 1,000,000 ₸ excluding VAT results in a VAT amount of 160,000 ₸ (16%), totaling 1,160,000 ₸ payable. These amounts are transferred to the table part “Goods” of the ESF from the related invoice.
Typical Processing/Exchange Scenarios
- Creation of outgoing ESF based on the invoice — during sale, when the “Invoice” has already been created in accounting.
- Receiving and registering incoming ESF from the ESF Information System — during purchase, when the supplier issued and sent the ESF.
- Creation of corrective ESF — when changing the price/quantity of previously shipped goods (discount, mis-sorting).
- Rejection of incoming ESF — when errors are found in the received ESF from the supplier.
- Revocation of outgoing ESF — when there is an error in the sent ESF before it is accepted by the buyer.
- Loading ESF from an XML file — when the ESF is received not through the ESF Information System, but as a file.
- Updating ESF statuses — regular synchronization of current statuses with the ESF Information System.
6. Related Objects and Input Based On
Underlying document for ESF:
- “Invoice (issued)” — outgoing ESF;
- “Invoice (received)” / incoming ESF from the ESF Information System.
Document flow chain:
Sale of Goods and Services → Invoice (issued) → ESF (outgoing) → sending to the ESF Information System.
Receipt of Goods and Services ← Invoice (received) ← ESF (incoming) ← ESF Information System.
Input based on:
- ESF is entered based on the invoice (sale);
- corrective/corrected ESF is entered based on the previously issued ESF.
Related electronic documents of the RK: SCT (accompanying invoices for goods) — used in conjunction with ESF for goods subject to traceability and work with the same virtual warehouse registers.
Directories and Registers: Organizations, Counterparties, Contracts, Nomenclature, Warehouses; registers GoodsInVirtualWarehouses, GoodsInVirtualWarehouseReserve.
7. Extension Points
- Configuration extensions (adapters/subscriptions): subscriptions to events
BeforeSaving,OnSaving,ProcessingConductingof the document for additional validation or enrichment of ESF data. - Additional attributes and information (characteristics plan mechanism) — for industry attributes without changing the configuration.
- Overridable common modules for integration with the ESF Information System — points for customizing exchange formats, signing rules, and XML parsing.
- Exchange/conversion rules for uploading/downloading ESF to external systems (XML).
- Service table part “Typical Errors” — a standard point for adding custom checks: the result is recorded in the columns
TextandField. - Printed forms and layouts — the ability to add custom representations of ESF.
Requires verification (version-specific): exact names of object module procedures, composition of additional header attributes, and the complete list of table part columns may differ in the specific build 3.0.74.2 — check with the configurator. The exchange format with the ESF Information System and requirements for digital signatures depend on the current version of the KGD MF RK regulations.