The law is already in force, yet most forwarders have no built-in mechanism in their transport systems: rewriting a TMS is slow and expensive, and operating without the document is not an option. We close that gap with a separate service that stands next to your system and takes the document flow on itself.
Short and to the point, without ten pages of regulatory retelling.
Since 1 September 2026 the electronic forwarder order, the electronic forwarding receipt and the electronic warehouse receipt are drawn up electronically. There is no paper alternative, and the rule also covers shipments that previously had no documents at all.
The format of the electronic forwarder order was approved by Federal Tax Service Order No. ЕД-1-26/277@ of 28 April 2026, and the exchange procedure by Government Resolution No. 469 of 27 April 2026. You cannot invent your own format: the structure is fixed and validated.
The document is created and signed in an EDI operator's service, from where it is routed to the counterparty and simultaneously lands in the state information system for electronic transport documents.
If a forwarder engages another forwarder, an order is issued for every leg of the chain, with the next participant acting as the client. A manual process breaks here first.
These are the most commonly confused, yet they differ in purpose and timing.
Defines the terms of work: what is carried, where and on what conditions. Issued before transport. It consists of parts: the client creates and signs theirs, the forwarder signs theirs to confirm agreement, and the client may withdraw the order with a separate part.
Records a fact: the forwarder has taken the cargo. Unlike the order, it is issued at the moment the cargo is actually accepted, not in advance.
Accompanies the cargo in transit and evidences the carriage contract. The order defines the terms of work; the waybill is used in the transport itself.
Used when the forwarder never physically takes the cargo: an order request and a waybill are issued instead, signed with the carrier and the consignee by the client themselves.
Six steps from a request to a mark in the state system. In our service a human is involved only where the law requires a signature.
The request arrives from your source: a transport system, an accounting system, a spreadsheet, a file or an API call.
The service fills the approved structure: parties, cargo, route, addresses and signatory details.
Mandatory fields, reference data and internal consistency are checked. An error is caught before sending rather than in a rejection from the state system.
The document is signed with an enhanced qualified electronic signature. This is the step that stays with a human — and the only one where a human is genuinely needed.
The signed document goes to the counterparty through an EDI operator and lands in the state system at the same time.
The service tracks counter-signature, withdrawals and rejections, keeps the history and returns the status to your system.
Most transport systems were designed before the requirement existed. A modification depends on the vendor, the timeline and the budget — while the documents are needed now.
One client sends a spreadsheet, another an email, a third is integrated through an API. Normalising that by hand is separate work on every single shipment.
With dozens of shipments you can do the documents by hand. At hundreds it turns into a queue, errors and rejections from the state system.
Every link needs its own document. Where there used to be one paper set, there is now a set of electronic documents for each leg.
It does not replace your transport system and does not require rewriting it. It takes the request in whatever shape you have it and carries the document through to the state system.
A spreadsheet, a file in a folder, an API, an accounting or a transport system — the service assumes sources differ and change over time.
The structure follows the format approved by the tax authority, not somebody's interpretation of the document.
Mandatory fields, reference data and consistency. A rejection from the state system costs more than a check on the way in.
Works with an EDI operator through which the document reaches the counterparty and the state system.
You can see what is signed, what awaits the counterparty, what was withdrawn and what was rejected — per document and across the whole flow.
The status and a link to the document go back, so nobody has to watch two interfaces.
A standalone product, not an adapter to one carrier. The module sits next to your accounting system and closes electronic transport documents with any counterparty: your own carriers, forwarders and clients. The order is created where it always was — the rest happens by itself.
1C, SAP or another ERP — wherever the order is born today
Parses the order, assembles documents, signs them, tracks statuses
Documents go to the state system, the order to whichever carrier you chose
Five to ten minutes of manual work on every order — on every single shipment.
Create the order in your own system, check it, sign it. Nothing else to do.
The module is not tied to us. It serves your existing carriers and forwarders equally — we do not think it is right to sell a tool that only works one way.
Any counterparty with an EDI mailbox. The carrier list is yours and can change without touching the module's configuration.
As a separate option the module connects directly to BIOCARD: the order goes across without shuffling files, and the shipment number, statuses, in-transit temperature and proof of delivery come back. An addition, not a condition.
Once the exchange is running it is convenient to receive the rest through it too — provided the carrier supplies it. BIOCARD does out of the box; others supply what they supply.
The module stays your tool: it works as a standalone system and does not require you to move into anybody's portal — including ours.
Working screens, not a concept. Counterparty details are blurred out — we are showing the interface, not somebody else's data.
A handful of real requests in their existing shape is enough. We show the service working on them, before any commitments.
We set up intake from your system, folder or API. Your transport system stays untouched.
We work with your EDI operator and your electronic signature — there is no need to change either.
For a while documents are produced in parallel with your current process. We switch over when there are no discrepancies.
No. The service installs alongside and pulls requests from it or from any other source. That is precisely why it can go live quickly — rewriting a transport system would take months.
Yes, we work through your operator. There is no need to change the operator or your electronic signature.
The parties sign with their own enhanced qualified signatures: the client signs their part, the forwarder theirs. The service prepares the document and brings it to the signature stage but never signs on a person's behalf.
An order is issued for every link, with the next participant acting as the client. The service produces documents across the whole chain, not just the first leg.
That is a standard scenario. A spreadsheet is as valid a source as an API: the service parses it and assembles the document.
A demo is immediate, on your own requests. A pilot usually takes weeks, because the service already exists and runs; the time goes into connecting the source and agreeing things with the operator.
Note. This material is for information only and is not legal advice. Confirm the document procedure with your own EDI operator and legal counsel.
Twelve checks from our own rollout: request sources, reference data, signatures, roles and EDI exchange. No sign-up.
Open the checklist →AI takes over the routine of logistics and warehouse teams — decisions stay with people
More about this solution →The assistant works in 1C through permitted operations — every action is named and logged
More about this solution →Send two or three real requests in any format — we will show how the document is assembled from them and tell you how long connecting will take.