Diadok, SBIS, Taxcom, or Astral: Choosing EDI for 1C

Start with a document workflow map: where the document originates, who signs it, how it reaches the counterparty, and where the accountant sees the result. Then compare operators using the same volume and set of operations. The five questions below help define requirements before discussing plans.

The 1C module handles standard operations; the API is needed for additional logic, other accounting systems, and AI agents. Compare documentation, authorization, the test environment, limits, and access fees separately from outgoing traffic charges. The terms below apply to the specified product, not to all of the operator's services.

Using one set of test documents, check the full cycle: preparation → signing → sending → counterparty response → status update in 1C → export of the archive with signatures.

The pilot must cover rejection, document correction, an expired token, and retrying a request after a connection loss. A successful HTTP response does not mean the counterparty accepted the document. Record document IDs and define a rule preventing retries from creating duplicates.

An AI agent can help fill in and check a draft. Signing authority, approval, and whether sending is permitted are governed by separate process rules. Generating a client from a specification does not solve these tasks by itself.

For evaluation Diadoc API integrations or general EDI exchange in 1C prepare document examples and a list of databases and counterparty operators: use them to verify the connection method and scope of work.

Large operators offer automated invitation and roaming workflows. However, the result depends on the specific mailboxes, selected product, document, and settings on both sides. Operator size does not replace a pilot: test sending, counter-signing, rejection, correction, and status return to 1C.

For each significant counterparty, record the operator, mailbox ID, and test result. If the invitation does not go through automatically, clarify the application process and responsible person on each side. Do not move all counterparties to one operator solely because of the service name.

Transport and HR documents must be checked separately. Working UPD roaming does not mean that the same integration supports all roles and forms for special documents. When choosing an EPD information system, agree on the workflow with the carrier, consignor, and consignee.

Two operators can handle different company tasks. A typical setup is exchanging UPD with suppliers through Diadoc because most counterparties have historically used it; statutory reporting through the Taxcom service built into 1C; and HR documents in Saby Staff (SBIS HR EDI) or Kontur.HR EDI. Each workflow follows its own rules, and requiring one operator for everything may cost more than two contracts.

That's how our client chose too—a manufacturing and trading holding in the food industry with tens of thousands of counterparties. Documents went through different EDI operators, statuses had to be checked in each personal cabinet. The holding embedded SBIS module into 1C and made 1C the single point of work: documents, statuses, and archive—in one interface, operator channels—under the hood. Details—in case study of SBIS implementation for a food industry holding.

The rule that makes a mixed landscape manageable: the accounting system, not operators’ portals, should be the single source of truth. There are two options. First, install both operators’ modules in 1C with agreed rules for logs, IDs, and statuses; installing two modules alone does not create a unified log. Second, use an integration bus or direct API integration: 1C creates the document, the bus routes it to the appropriate operator, and statuses and the archive return to 1C. A bus makes sense when reused for multiple exchanges. When changing operators, still verify formats, signatures, statuses, and the archive; switching the connector alone may not be enough. This implementation is described on the page EDI in 1C.