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

Comparing operators by price list—a path to rework in a year: all have similar rate structures that change faster than any comparison table survives. Solid ground for choice—your own landscape. Five questions to help you choose an EDI operator for your landscape—before talking to managers.

The 1C module covers standard scenarios, but automation isn't limited to them: custom accounting circuits, integration buses, and AI agents work with the operator via API. And here the price-list comparison fails again: the right to use the API itself may be paid, issued manually, or work with limitations that surface only after contract signing.

Worth checking: whether documentation is open without registration, whether there's a machine-readable specification and SDK, whether there's a sandbox for testing without a production environment, how much API access costs—and what limits await in production. Unlike document packages, we list API access pricing in figures: these are threshold payments that vary significantly. Terms and prices—according to operator price lists published for July 2026.

For an AI agent, the picture looks like this.

With Diadoc, an agent can generate a client from OpenAPI specification and deploy in the test environment with minimal human involvement—but API access costs 26,900 ₽/year on top of document bundles, and the account manager issues client_id. How we build such integrations—on this page integrations with Diadok via API.

SBIS offers the most predictable API pricing: included in the 'Exchange with counterparties' tariff, limits publicly disclosed—but you'll code a client from HTML documentation: no OpenAPI specification, current SDK is ExtSDK2 (OLE/COM) only.

Taxcom publishes documentation and test environment addresses, but its Web API is the lowest-level of the four: your integration assembles document flow regulations and transport container, operator issues integrator ID, login/password access is read-only.

Astral's API is free: manual token generation in personal account, fully automatic authorization via qualified signature, no cloud signature in API; sandbox and test signatures require a contract—no try-before-buy.

Final rule: if automation will code and maintain the integration, compare not 'does it have API' but the trio 'spec + sandbox + access pricing'. How such a circuit assembles into a single work point in 1C — on the page EDO implementation in 1C.

The fear 'counterparties with another operator—we'll have to move everyone' is outdated. Between major operators—Diadoc, SBIS, Taxcom, Astral Kaluga—roaming sets up automatically: send a counterparty an invite directly from the service, they accept, exchange works. Between Astral and Taxcom, exchange is direct, without roaming: both operate within 1C-EDI technology. No applications, papers, or weeks of waiting—this is the result of auto-roaming standardization agreed by operators in the ROSEU association.

Problem areas remain in two cases. First—small and industry-specific operators: roaming may require applications and manual setup on both sides, with timelines stretching from days to weeks. If a key counterparty uses such an operator, test the roaming pair before signing the contract, not after. Second—special contours: electronic waybills don't transmit via inter-operator roaming at all; all participants in eWaybill preparation must use one GIS EDI operator. For standard invoices and acts, no such restrictions apply, but a pilot on one real counterparty pair is cheaper than resolving stuck documents at month-end.

Bottom line: if counterparties use the major four, roaming should not affect operator choice. It becomes an argument only when a significant share of document flow goes to counterparties at niche operators.

Running two operators simultaneously is not a workaround but common practice: law doesn't require a single operator, and circuit tasks differ. Typical setup: UPD exchange with suppliers through Diadok (majority counterparties historically there); regulated reporting through 1C's built-in service on Taxcom; HR documents in Saby Staff (SBIS KEDO) or Kontur.Diadok's KEDO. Each circuit follows its own rules, and the 'one operator for everything' requirement can 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 single point of control should be the accounting system, not individual operator portals. Two approaches exist. First—both operators' modules inside 1C: documents from different channels converge in one exchange log. Second—integration bus or direct API integration: 1C generates a document, the bus routes it to the needed operator, statuses and archives return to 1C. The second approach costs more upfront but doesn't tie document flow to any one operator: swapping a channel means swapping a connector, not rebuilding processes. How such implementation works—on the page EDI in 1C.