Unified inbound primary-document flow: how to bring EDI, PDFs, and email into 1C without manual data entry

Primary documents rarely reach a company through a single channel. One supplier sends a universal transfer document through EDI, another sends an acceptance certificate as a PDF, and a third emails an invoice scan. The accountant must open several systems, download files, find the counterparty, check the details, and re-enter the data in 1C.

The EDI operator transfers documents, statuses, signatures, and related events, but scans, unstructured PDFs, attachments, and corrected versions remain outside this channel. Therefore, the task goes beyond connecting SBIS or Diadoc: a unified process is needed for all incoming documents.

Within a group of companies, one mailbox or EDI account can receive documents for several legal entities. Routing is based on the recipient’s tax ID and registration code, operator unit, email address, contract, bank account, project, or site.

Rules must have priorities and produce explainable results. If the tax ID points to one organization but the contract is found in another database, the document must not be passed on silently: it goes to an exception queue with a description of the conflict.

The integration method depends on the configuration, workload, and security requirements. The standard OData-based REST interface of the 1C platform enables reading and modifying catalogs, documents, registers, tasks, and business processes via HTTP. Other projects use 1C HTTP services, configuration extensions, message queues, integration platforms, or scheduled file exchange.

The mechanism cannot be selected based on connection simplicity alone. Document volume, acceptable latency, load on 1C, integration-user permissions, retry handling, and status updates to the external system all matter. For companies that need this type of exchange, we design and implement 1C integrations with external systems.

Even a well-designed workflow cannot process every document automatically. The key interface is therefore an exception queue showing the reason for the stoppage, disputed fields, the original file, the suggested value, related objects in 1C, and permitted user actions.

The task should be specific: “contract not found,” “two counterparty records detected,” “amount differs from the order,” “document belongs to a closed period,” or “possible duplicate receipt.” After the issue is resolved, the system can remember the rule, but it should apply it automatically only within predefined boundaries.

Integration does not end with creating a document in 1C. The incoming workflow stores the processing status, accounting-system object ID, validation result, correction request, cancellation details, integration error, and number of retry attempts.

EDI provider APIs make it possible to retrieve content, signatures, current statuses, and event history. This makes the exchange two-way: the accountant sees not only the uploaded file but also the current status of the entire document workflow.

For the initial assessment, choose one high-volume workflow and collect examples of varying quality: a valid structured UPD, a standard PDF, a poor scan, a corrected version, a document without a contract, and a potential duplicate. These examples can be used to test routing, data quality, and the real limits of automation.

The assessment produces a map of sources and databases, a unified document model, a list of checks, an exception queue, and a pilot plan. This enables the gradual removal of manual entry without compromising accounting quality.