Electronic Document Flow in Uzbekistan: How to Set It Up
Practice4 minInnovialabs editorial team
In short
To work with electronic documents in Uzbekistan, a company needs an e-signature key, an account with an EDI operator such as Didox or Faktura.uz, and clean reference data; integrating with 1C and CRM removes manual entry and most errors.
How electronic document flow works in Uzbekistan
Electronic document flow (EDF) means exchanging legally binding documents electronically: invoices, acts of completed work, powers of attorney, contracts. A document becomes legally valid through an electronic digital signature (EDS).
The flow looks like this:
- The company creates a document with an EDF operator: in the web account, via API, or directly from its accounting system.
- It signs the document with its EDS key.
- The operator delivers the document to the counterparty and passes the data to the tax authority's information system.
- The counterparty accepts and signs the document, or rejects it with a reason.
Well-known operators include Didox and Faktura.uz; basic features are also available in the taxpayer's account on the tax service portal. Operators generally exchange documents with each other, so your counterparty does not have to use the same operator, but confirm this for the specific pair of operators.
What you need to start
- An EDS key for the director and, if needed, for employees who will sign documents. Keys are issued by accredited registration centers.
- Signing software for the browser (the E-IMZO module) installed on signers' computers.
- An operator account: registration usually works with the company's EDS key.
- Reference data: counterparty tax IDs (INN), IKPU product and service codes, unit-of-measure codes, VAT rates.
- Clear roles: who creates documents, who signs, who monitors incoming ones.
Step-by-step setup
- Obtain EDS keys and check their expiry. Validity is limited, so plan renewals ahead.
- Register with an operator and fill in company details.
- Prepare your catalog of goods and services with IKPU codes. A wrong code is one of the most frequent reasons for rejection.
- Issue a first document to a test or friendly counterparty and go through the full cycle: create, sign, receive, confirm.
- Assign an owner for incoming documents: supplier documents also need timely acceptance or rejection.
- Connect integrations once the manual process runs smoothly.
Integration with 1C and CRM
Manual entry in the operator's account works for dozens of documents a month. With hundreds, you need integration.
| System | What gets automated | How it is usually connected |
|---|---|---|
| 1C | Exporting outgoing invoices and acts, importing incoming ones, signing statuses | The operator's ready-made module or its API |
| CRM | Creating a document from a deal, tracking client signature | Operator API, status-change webhooks |
| Warehouse / ERP | Shipment documents, matching against supplier documents | Operator API |
Things to watch:
- A single source of truth. Create documents in one place, either 1C or CRM, otherwise duplicates appear.
- Synced reference data. IKPU codes, units and tax IDs must match in the accounting system and at the operator.
- Error handling. If the operator returns an error, the integration must show it to a user instead of silently skipping the document.
- Signing stays with a person. The EDS key should not sit on a shared server without control; signing is usually done at the authorized employee's workstation.
Common mistakes
- Wrong tax ID or buyer details: the document goes to the wrong company or is rejected.
- Wrong IKPU code or a unit of measure that does not fit the code.
- Wrong VAT rate or an error in the VAT-inclusive total.
- An expired EDS key, discovered on the day an urgent document must be signed.
- The key lives on one employee's laptop. They go on vacation and nobody can sign. Keep a backup signer.
- Unprocessed incoming documents. Supplier documents sit unanswered, which later breaks reconciliation and bookkeeping.
- Duplicates from working in 1C and the operator's account in parallel.
- No correction procedure. A wrong document must be cancelled or corrected according to the operator's rules, not overwritten with a new one.