ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Russia — FNS, UPD and EDF flows

Russia has deployed a national e-invoicing framework pivoting around FNS-accredited EDF (Electronic Document Flow) operators since 2014. The central schema, UPD (Universal Transfer Document), combines fiscal invoice (счёт-фактура) and delivery note into a single signed XML.

Regulatory timeline

  • 6 April 2011 — Law 63-FZ. Federal framework on electronic signature, distinguishes simple, enhanced unqualified and qualified signature (KEP), the only one recognised for tax documents.
  • 5 March 2012 — FNS Order ММВ-7-6/138@. Approves the first XML schema of electronic invoice (электронный счёт-фактура).
  • 21 October 2014 — FNS Order ММВ-7-15/155@. Introduces the UPD (Universal Transfer Document), unified invoice + delivery note + service act schema.
  • 1 January 2019 — Law 488-FZ Markirovka. Mandatory labelling (tobacco, medicines, furs, footwear…) with UPD transmission to Честный ЗНАК via EDF operator.
  • 1 January 2022 — Imported product traceability system. RNPT (shipment registration number) mandatory in the UPD for certain imported products (refrigerators, washing machines, transformers…).
  • 1 July 2022 — UPD format 5.02. Order ED-7-26/970@ update — traceability and Markirovka field extensions.
  • 1 April 2025 — UPD format 5.03. Update integrating ESBL (national label for sensitive products) and VAT adjustments.

Technical schema

The UPD (Универсальный передаточный документ) format is an FNS-mandated XML, encoded in windows-1251 with Russian-named tags. Features:

  • Function (Функция): СЧФ (fiscal invoice only), ДОП (transfer act only), СЧФДОП (combined invoice + act).
  • КНД 1115131: FNS form code for UPD.
  • СвПрод / СвПокуп: seller / buyer blocks with INN, KPP, РФ address (region codes, OKATO).
  • СодФХЖ1: document lines with ОКЕИ (units), ОКПД2 (product nomenclature), VAT rate (НалСт), RNPT for traceable imported products.
  • Detached signature: KEP as CAdES-BES or CAdES-X Long Type 1, standards ГОСТ Р 34.10-2012 (key) and ГОСТ Р 34.11-2012 (hash).

Minimal example of an SCHFDOP UPD (combined invoice + act):

xmlupd-5.03.xml
<?xml version="1.0" encoding="windows-1251"?>
<Файл ИдФайл="ON_NSCHFDOPPR_2BM-7707083893_2BM-7706107510_..."
      ВерсФорм="5.03"
      ВерсПрог="Ediverse 1.0">
  <Документ КНД="1115131" Функция="СЧФДОП" ДатаИнфПр="16.05.2026"
            ВремИнфПр="10.30.00" НаимЭконСубСост="Ediverse Demo LLC">
    <СвСчФакт НомерСчФ="142" ДатаСчФ="16.05.2026">
      <СвПрод>
        <ИдСв>
          <СвЮЛУч НаимОрг="Ediverse Demo LLC"
                  ИННЮЛ="7707083893" КПП="770701001"/>
        </ИдСв>
        <Адрес>
          <АдрРФ Индекс="125009" КодРегион="77"
                 Город="Москва" Улица="Тверская" Дом="13"/>
        </Адрес>
      </СвПрод>
      <СвПокуп>
        <ИдСв>
          <СвЮЛУч НаимОрг="Customer Demo LLC"
                  ИННЮЛ="7706107510" КПП="770601001"/>
        </ИдСв>
      </СвПокуп>
      <ДенИзм КодОКВ="643"/>
      <СодФХЖ1>
        <СвТов НомСтр="1" НаимТов="Cloud services May 2026"
               ОКЕИ_Тов="796" КолТов="1.00" ЦенаТов="50000.00"
               СтТовБезНДС="50000.00" НалСт="20%" СумНал="10000.00"
               СтТовУчНал="60000.00"/>
      </СодФХЖ1>
    </СвСчФакт>
  </Документ>
</Файл>

Submission flow

The Russian model is a 5-corner via EDF operators: the seller signs the UPD with their KEP, deposits with their operator, which routes to the buyer's operator (roaming) if different. The buyer signs the receipt acknowledgement, and the whole flow is replicated to the FNS via automatic reporting.

textupd-flow.txt
┌─────────────┐    ┌─────────────────┐    ┌─────────────┐
│ RU supplier │───>│ EDF operator    │───>│ RU customer │
│ (ERP, UPD)  │    │ (Diadoc, Kontur,│    │ (receive)   │
│ + KEP sig   │    │  Taxnet, Tensor)│    │ + ack       │
└─────────────┘    └────────┬────────┘    └─────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ FNS (nalog.gov.ru│  ← automatic
                  │  via operator)   │     fiscal reporting
                  └──────────────────┘

For Markirovka-labelled goods (tobacco, alcohol, medicines, footwear…), the operator transmits in parallel the DataMatrix codes to the Честный ЗНАК system (CRPT). For traceable imported goods, the RNPT declared in the UPD is automatically replicated to the FNS for quarterly report.

Validation

  • FNS — e-invoicing portal: nalog.gov.ru/el_doc — official UPD XSD schemas, accredited EDF operator lists, KEP certification authority lists.
  • Diadoc (СКБ Контур): diadoc.ru — leading Russian EDF operator, REST API, public sandbox.
  • СБИС (Tensor): sbis.ru — EDF operator, integrated ERP, high-volume.
  • Честный ЗНАК (CRPT): честныйзнак.рф — national Markirovka traceability system tied to the UPD.

Common pitfalls

  1. Mandatory windows-1251 encoding. FNS XSDs reject UTF-8 XML: the declaration encoding="windows-1251" is required and the content must actually be encoded in CP1251. A UTF-8 BOM → CP1251 conversion without out-of-table character purge breaks proper names and addresses containing non-Russian characters (originally accented Latin letters, technical symbols).
  2. KEP ГОСТ vs RSA. A signature with an RSA certificate (even qualified EU eIDAS) is not recognised. The KEP must use ГОСТ Р 34.10-2012 on a Russian elliptic curve and ГОСТ Р 34.11-2012 (Streebog hash), with certificate issued by a CA accredited by the Ministry of Digital Development (Минцифры).
  3. Cross-operator roaming. Seller on Diadoc and buyer on Tensor: the exchange goes through a roaming agreement between operators. Not all pairs are covered, and some require both parties to explicitly activate roaming. Check the roaming matrix before onboarding a key customer.
  4. UPD format vs XSD version. The FNS regularly publishes revisions (5.01, 5.02, 5.03…), each with its effective date and a tolerance period for the previous version. Issuing in 5.02 after the 5.03 switchover without tolerance triggers an EDF operator rejection.
  5. Markirovka traceability and RNPT. Forgetting DataMatrix codes on the UPD of a labelled product: the operator transmits anyway, but the Честный ЗНАК reconciliation fails and the product appears as "not delivered" in the chain, creating an immobilisation risk at the buyer's site.