Diadoc module for 1C in 2026: what changed and what to update

We use a fourth approach: an integration layer between the EDI operator and 1C:Fresh through the operator API and 1C web services.

The accounting system stays in the cloud and requires neither a server nor external components, while documents, statuses, and links to accounting objects are delivered to it automatically. This works with more than just Diadoc.

The approach is the same for any operator that has a programmatic interface: if the operator is not in the standard list

There is nowhere to install Fresh or the module, but the exchange can still be assembled - only the adapter for a specific API changes, while the document routes and matching rules remain yours.

What such integration includes: receiving incoming documents and sending outgoing ones, matching with counterparties and contracts in accounting, transferring signing statuses, processing structured formats (UTD 5.03) and signing with MChD, as well as an exchange log that shows the fate of each document.

Observability is not a luxury here: in a cloud environment you cannot inspect logs on the server, so the exchange history and error analysis must be built in from the start. The boundaries are clear.

Integration does not remove the operator's signing requirements and does not make exchange legally significant where there is no agreement between operators. It is also not free: it requires development and support, which only make sense at a certain document volume - if only a few documents are processed per month, the web portal is cheaper.

For counterparty exchange, EMCHD is issued in unified format 003—both government bodies and EDI operators accept it.

Format 5.03 remains only for tax reporting to the Federal Tax Service, while registration of previous formats has been discontinued: 5.02—since January 10, 2025; 5.01—since March 1, 2025; previously issued powers of attorney remain valid until expiration.

Registered EMCHD is stored in the Federal Tax Service's distributed registry, so you don't need a separate power of attorney for each operator—counterparties verify it in the registry. As of February 1, 2026, an order takes effect

Ministry of Digital Development Order No. 1001 (November 5, 2025): new EMCHDs must include the representative's SNILS, INN, date of birth, power of attorney validity period, and authority name; passport data are no longer required. Powers of attorney issued before this date do not need to be reissued. In the bundle

Diadoc and 1C workflow: an employee logs into the module with a personal certificate; EMCHD is issued via Kontur.Doverennost service or uploaded as a signed XML file; the manager signs the power of attorney with their certificate—then the module signs documents with the employee's enhanced qualified signature linked to the EMCHD.

Kontur.Diadoc is not the only EDI operator: there are SBIS/Tensor, Takscom, Kaluga Astral, and others.

The choice depends on the industry, document volume, and accounting systems.

Key for 1C: auto-roaming works between major operators - exchange is set up by automatically sending an invitation, with no roaming request or paperwork (ROSEU association), meaning 0 requests.

If your counterparties use another operator, see 1C and SBIS integration or 1C and Taxcom.

How to choose between them for your specific landscape—configurations, product marking, transportation, and roaming—we covered in comparison of Diadoc, SBIS, and Taxcom.

A separate workflow starts on September 1, 2026 for mandatory transport documents: transport consignment notes move into GIS EPD through accredited EPD IS operators, and a standard EDI connection is not enough.

A breakdown of the transition is in the article about ETrN and GIS EPD in 1C.