Skip to content

D394 — informative on domestic supplies/purchases

Informative declaration on supplies/services and acquisitions performed on national territory between VAT-registered persons (and with unregistered persons), filed with the same periodicity as the VAT return. This file is a completion guide: what the declaration reports, who files it and when, and how each section/attribute anafpy authors maps onto the form — followed by the technical XSD/DUK layer. ANAF's validator jar (D394Validator.jar) and its published instructions are the authority; this guide is a distilled bridge, not a re-implementation of the rules. By far the widest schema of the common forms (~260 attributes across 9 element types). Everything below the "Common scenarios" instances was proven hands-on on 2026-07-17 against J8.0.2 (XSD v5, feed directory D394_31).

D394 is the declarație informativă privind livrările/prestările și achizițiile efectuate pe teritoriul național de persoanele înregistrate în scopuri de TVA. It reports, per partner and per operation type, every domestic transaction that carried an invoice — so ANAF can cross-match every seller's declared sales against every buyer's declared purchases and reconcile the per-partner totals against the filer's own VAT return (D300). It is the tax authority's principal domestic anti-fraud instrument; it settles no tax itself (purely informative).

  • Current model: approved by OPANAF 77/2022 (M.Of. 100/01.02.2022), amending the base order OPANAF 3769/2015. The post-Aug-2025 VAT-rate change (Legea 141/2025 — 21% standard / 11% reduced) was implemented by a validator update (J8.0.0, 15 Sep 2025; J8.0.2 correction 17 Sep 2025) and the soft form D394_26092025, not by a new form order: v5 adds …21/…11 rate columns alongside the historic 24/20/19/9/5. So the governing order stays 77/2022 while the rate columns track the decont — see Special attention & gotchas.
  • Periodicity: the same fiscal period as the VAT return, carried by tip_D394 (L/T/S/A), not by a rectificative flag.

Who files & when

  • Who: every person registered for VAT under art. 316 of the Fiscal Code files a D394 for every fiscal period, including nil periods (a period with no operations still requires a declaration — op_efectuate="0"; see the nil scenario). It covers domestic invoiced supplies/acquisitions only — including advances, reverse-charge ("taxare inversă") and cash-accounting ("TVA la încasare") invoices, regardless of when VAT becomes exigible. Intra-EU operations go on D390, not here; imports/exports are out of scope.
  • Deadline: the 30th (inclusive) of the month following the reporting period — note this is later than D300's 25th (the two forms cover the same period but have different due dates). Confirmed by the ANAF assistance note and the current soft-form instructions.
  • Monthly vs quarterly: tip_D394 must equal the taxpayer's elected VAT fiscal period (same €100,000-turnover / intra-EU-acquisition election that drives the D300 period). The structure annex flags the intra-EU-acquisition case explicitly: a quarterly VAT payer who makes an intra-EU acquisition in month 02/05/08/11 loads that period as a quarterly (T) D394 with the cumulated value of the two months, and the following period switches to monthly (L). tip_D394="S" is valid only for luna 06/12, tip_D394="A" only for luna 12.
  • Corrections — full replacement, no rectificative checkbox: D394 has no "declarație rectificativă" flag. If, after filing, you find omissions or errors, you file a new, completely re-composed declaration for the same period containing all operations (the corrected ones and every operation that was already correct), and it replaces the prior submission in its entirety. There is no delta/append mode — never file only the changed rows.

Filling guide

The document is a root element with attributes plus a fixed sequence of child elements (XSD order): informatii (exactly one, required), then optional repeating rezumat1, rezumat2 (≤5), serieFacturi, lista, facturi, op1, op2. informatii must come first, before any rezumat1.

The two layers. The summaries (rezumat1 per partner-type × rate, rezumat2 per rate) are what the printed form shows; the detail (op1 per-partner rows, op2 cash-register aggregates) is what those summaries are computed from. The jar enforces that every summary equals the sum over its detail rows — you cannot fill one layer and not the other.

totalPlata_A is a control sum — and its formula differs from D300's. Rule: totalPlata_A = nrCui1 + nrCui2 + nrCui3 + nrCui4 + Σ rezumat2(bazaL + bazaA + bazaAI) (the partner counts plus each rate-total's supply/acquisition bases). It is not the sum of every numeric attribute (that is D300's rule), and it is not an amount payable (D394 settles nothing). A nil form has totalPlata_A="0".

Root header (identification block)

Attribute Field Notes
luna / an Perioada de raportare month 1–12 / year ≥ 2016
tip_D394 Tip D394 enum L/T/S/A — the filing periodicity
sistemTVA Sistemul de TVA 0 normal, 1 cash accounting (TVA la încasare)
op_efectuate Au fost efectuate operațiuni 0 = nil (no ops), 1 = ops performed; must agree with the presence of detail
prsAfiliat Operațiuni cu persoane afiliate 0/1
cui Cod de înregistrare în scopuri de TVA jar enforces the CUI check digit
caen Cod CAEN closed CAEN enumeration in-XSD
den / adresa Denumire / Adresă domiciliu fiscal required
telefon Telefon required on D394 (optional on D300); fax/mail optional
denR / functie_reprez / adresaR Reprezentant legal required; cifR/telefonR/faxR/mailR optional
tip_intocmit Tip persoană care întocmește 0 juridic, 1 fizic
den_intocmit / cif_intocmit Preparer name / CIF if tip_intocmit=1, cif_intocmit is a CNP/NIF
calitate_intocmit / functie_intocmit Calitate / Funcție întocmitor conditional — rule R30, below
optiune Consimțământ consultare ANAF 0/1 (schimb_optiune optional)
totalPlata_A Suma de control the control sum above

Preparer conditional (R30) — the one non-obvious header cross-check: if tip_intocmit=0, or tip_intocmit=1 with functie_intocmit empty, then calitate_intocmit must be filled. A self-prepared declaration therefore needs calitate_intocmit even though the XSD marks it optional.

informatii — the statistics block (all counters required)

21 required attributes; on a nil form every one is 0.

Attribute Meaning
nrCui1…nrCui4 count of distinct partners per tip_partener 1/2/3/4 (nrCui1 = COUNT(DISTINCT op1.cuiP) for tip_partener=1; nrCui2 = number of op1 rows for tip_partener=2)
nrFacturi / nrFacturi_benef / nrFacturi_terti invoices issued in period / by beneficiaries / by third parties (tied to serieFacturi tip 2/3/4)
nr_BF_i1, incasari_i1, incasari_i2 cash-register (AMEF) receipts — from op2
nrFacturiL_PF / nrFacturiLS_PF / val_LS_PF obligatorily 0 since 01.01.2017 (vestigial)
tvaDedAI24…tvaDedAI5 deductible VAT from cash-accounting suppliers per rate — 0 when sistemTVA=0
solicit requests VAT refund (0/1); when 0, the whole achizitii*/BUN*/Prest*/efectuat block must be absent

rezumat1 — per partner-type × rate summary (the "cartușe")

Repeating, keyed by (tip_partener, cota) unique. Carries the delivered (facturiL/bazaL/tvaL) and acquired (facturiA/bazaA/tvaA, facturiAI/bazaAI/tvaAI, …) counts/bases/VAT for that partner category and rate, split by operation type. Each aggregate equals the sum over matching op1 rows (e.g. bazaL = Σ op1.baza for op1.tip=L, same tip_partener, same cota). Optional child detaliu breaks reverse-charge lines down by product.

Operation types (op1.tip / the rezumat1 column families):

Code Meaning
L livrări (supplies) — normal regime
A achiziții (purchases) — normal VAT
AI achiziții de la persoane care aplică TVA la încasare
C achiziții cu taxare inversă (reverse-charge purchases)
V livrări cu taxare inversă (reverse-charge supplies) — no VAT column
LS livrări în regim special (agenții de turism, second-hand, artă, colecție, antichități)
AS achiziții în regim special
N achiziții de la persoane neînregistrate în scopuri de TVA (tip_partener=2)

Partner types (tip_partener):

Code Meaning
1 persoane impozabile înregistrate în scopuri de TVA în România
2 persoane neînregistrate în scopuri de TVA
3 persoane nestabilite în RO, stabilite în alt stat membru, neînregistrate/neobligate
4 persoane nestabilite în RO și nestabilite pe teritoriul UE

cota accepts 0,5,9,11,19,20,21,24; cota=0 is allowed only when tip is in LS,AS,N,V. Per-type tip constraint: tip_partener=1 → tip≠N; tip_partener=2 → tip∈(L,LS,N); tip_partener∈(3,4) → tip∈(L,LS,C).

detaliu.bun — product nomenclature (reverse-charge / anti-fraud goods; the bun code the reverse-charge line is broken down by). For tip_partener=1: 21–31 or 36; for tip_partener=2: 21–23 or 32–35.

bun Goods category bun Goods category
21 Cereale și plante tehnice 29 Telefoane mobile
22 Deșeuri feroase și neferoase 30 Microprocesoare
23 Masă lemnoasă 31 Console de jocuri, tablete PC și laptopuri
24 Certificate de emisii de gaze cu efect de seră 32 Terenuri (tip_partener=2)
25 Energie electrică 33 Construcții (tip_partener=2)
26 Certificate verzi 34 Alte bunuri (tip_partener=2)
27 Construcții / terenuri 35 Servicii (tip_partener=2)
28 Aur de investiții 36 Gaze naturale

rezumat2 — per-rate totals (≤5 sections)

Filled only when op_efectuate=1; keyed by cota. Aggregates op1 across all partner types for that rate: nrFacturiL/bazaL/tvaL (from tip=L), nrFacturiA/bazaA/tvaA (from tip∈{A,C}), nrFacturiAI/bazaAI/tvaAI (from tip=AI), plus the simplified-invoice sums (bazaFSL*/TVAFSL*/bazaFSA*/…), cash-receipt bases (baza_incasari_i1/i2, tva_incasari_i1/i2 — required when cota≠24, rules R105–R108) and the vestigial bazaL_PF/tvaL_PF (0). The bazaL/bazaA/bazaAI here are the terms of the totalPlata_A control sum.

serieFacturi / lista / facturi — invoice-level sections

  • serieFacturi (invoice number ranges): tip = 1 alocate / 2 emise / 3 emise de beneficiari / 4 emise de terți; nrI required, serieI/nrF optional; den/cui filled only for tip∈(3,4). Required trap: if any op1 with tip∈(L,LS,V) exists, there must be at least one tip=1 and one tip=2 section (rule R112), and informatii.nrFacturi>0 iff a tip=2 section exists.
  • lista (cash-heavy sectors): keyed by (caen, cota, operat) unique, with valoare/tva. operat = 1 livrări bunuri / 2 prestări servicii. caen is a closed 14-code list: 1071 cofetărie/patiserie, 4520 spălătorie auto, 4730 retail carburanți, 47761 flori/plante/semințe, 47762 hrană animale de companie, 4932 taxiuri, 55101 hoteluri, 55102 pensiuni, 56103 restaurante, 5630 baruri, 812 curățenie, 9313 fitness, 9602 coafură/înfrumusețare, 9603 pompe funebre.
  • facturi (special invoices): tip_factura = 1 stornată / 2 anulată / 3 autofactură / 4 în calitate de beneficiar în numele furnizorilor; nr required; per-rate baza…/tva… columns.

op1 — per-partner detail rows (+ op11 product breakdown)

Attribute Meaning
tip / tip_partener / cota operation type / partner type / VAT rate (legends above)
cuiP / denP partner CUI (validated for tip_partener∈{1,2}; (cuiP,tip,cota) must be unique) / name (required)
taraP,locP,judP,strP,nrP,blP,apP,detP partner address — filled only for tip_partener=2 with cuiP null (unidentified persons); judP=null when taraP≠RO
tip_document 1 facturi / 2 borderouri / 3 file carnet / 4 contracte / 5 alte documente — required for tip_partener=2 and tip=N
nrFact / baza / tva invoice count / base (required) / VAT — tva required for tip∈(L,C,A,AI), else null
child op11 reverse-charge product breakdown: nrFactPR, codPR (product code), bazaPR, tvaPR — appears for tip∈(V,C) etc.

op11.codPR is the fine product code inside a reverse-charge operation. For cereals/technical plants (bun=21) it is a multi-digit CN code — 1001 grâu, 1002 secară, 1003 orz, 1004 ovăz, 1005 porumb, 1201 soia, 1205 rapiță, 120600 floarea-soarelui, 121291 sfeclă de zahăr, 10086000 triticale, 120400 in; for the other categories codPR just repeats the 2-digit bun code (22…35). When one reverse-charge invoice carries several goods, put nrFactPR=1 on the line with the largest base/VAT and 0 on the rest.

op2 — cash-register (AMEF) monthly aggregates

Repeating (≤24), keyed by (tip_op2, luna) unique. tip_op2 = I1 (receipts through AMEF / fiscal receipts) or I2 (receipts from activities exempt from AMEF). Carries nrAMEF (null for I2), nrBF, total, and per-rate baza…/TVA… (20/9/5/19/21/11). total ≥ baza20+baza19+baza9+baza5.

Common scenarios

Both instances validated clean (ok) against D394Validator.jar J8.0.2 on 2026-07-17. cui="1234565" and the partner CUIs 2000007/2000015 are all check-digit valid.

1 — Nil declaration (op_efectuate="0"): only the header + an all-zero informatii; no summaries or detail; totalPlata_A="0".

<?xml version="1.0" encoding="UTF-8"?>
<declaratie394 xmlns="mfp:anaf:dgti:d394:declaratie:v5"
  luna="6" an="2026" tip_D394="L" sistemTVA="0" op_efectuate="0"
  cui="1234565" caen="6201" den="EXEMPLU TEST SRL"
  adresa="Mun. Bucuresti, Str. Exemplu nr. 1" telefon="0211234567"
  totalPlata_A="0"
  denR="Popescu Ion" functie_reprez="Administrator"
  adresaR="Mun. Bucuresti, Str. Exemplu nr. 1"
  tip_intocmit="0" calitate_intocmit="Administrator"
  den_intocmit="Popescu Ion" cif_intocmit="1234565"
  optiune="0" prsAfiliat="0">
  <informatii nrCui1="0" nrCui2="0" nrCui3="0" nrCui4="0" nr_BF_i1="0"
    incasari_i1="0" incasari_i2="0" nrFacturi_terti="0" nrFacturi_benef="0"
    nrFacturi="0" nrFacturiL_PF="0" nrFacturiLS_PF="0" val_LS_PF="0"
    tvaDedAI24="0" tvaDedAI21="0" tvaDedAI11="0" tvaDedAI20="0" tvaDedAI19="0"
    tvaDedAI9="0" tvaDedAI5="0" solicit="0"/>
</declaratie394>

2 — Typical SME month (op_efectuate="1"): one 21% domestic sale (10 000 base / 2 100 VAT) to a VAT-registered client and one 21% domestic purchase (4 000 / 840) from a VAT-registered supplier. Two op1 rows feed one rezumat1 (tip_partener 1, cota 21) and one rezumat2 (cota 21); because an L operation exists, both a tip=1 and a tip=2 serieFacturi are present. nrCui1=2 (two distinct partners); totalPlata_A = 2 + (10000+4000+0) = 14002.

<?xml version="1.0" encoding="UTF-8"?>
<declaratie394 xmlns="mfp:anaf:dgti:d394:declaratie:v5"
  luna="6" an="2026" tip_D394="L" sistemTVA="0" op_efectuate="1"
  cui="1234565" caen="6201" den="EXEMPLU TEST SRL"
  adresa="Mun. Bucuresti, Str. Exemplu nr. 1" telefon="0211234567"
  totalPlata_A="14002"
  denR="Popescu Ion" functie_reprez="Administrator"
  adresaR="Mun. Bucuresti, Str. Exemplu nr. 1"
  tip_intocmit="0" calitate_intocmit="Administrator"
  den_intocmit="Popescu Ion" cif_intocmit="1234565"
  optiune="0" prsAfiliat="0">
  <informatii nrCui1="2" nrCui2="0" nrCui3="0" nrCui4="0" nr_BF_i1="0"
    incasari_i1="0" incasari_i2="0" nrFacturi_terti="0" nrFacturi_benef="0"
    nrFacturi="1" nrFacturiL_PF="0" nrFacturiLS_PF="0" val_LS_PF="0"
    tvaDedAI24="0" tvaDedAI21="0" tvaDedAI11="0" tvaDedAI20="0" tvaDedAI19="0"
    tvaDedAI9="0" tvaDedAI5="0" solicit="0"/>
  <rezumat1 tip_partener="1" cota="21"
    facturiL="1" bazaL="10000" tvaL="2100"
    facturiA="1" bazaA="4000" tvaA="840"
    facturiAI="0" bazaAI="0" tvaAI="0"
    facturiC="0" bazaC="0" tvaC="0"/>
  <rezumat2 cota="21"
    bazaFSLcod="0" TVAFSLcod="0" bazaFSL="0" TVAFSL="0"
    bazaFSA="0" TVAFSA="0" bazaFSAI="0" TVAFSAI="0" bazaBFAI="0" TVABFAI="0"
    nrFacturiL="1" bazaL="10000" tvaL="2100"
    nrFacturiA="1" bazaA="4000" tvaA="840"
    nrFacturiAI="0" bazaAI="0" tvaAI="0"
    baza_incasari_i1="0" tva_incasari_i1="0"
    baza_incasari_i2="0" tva_incasari_i2="0"
    bazaL_PF="0" tvaL_PF="0"/>
  <serieFacturi tip="1" serieI="AFCT" nrI="1" nrF="100"/>
  <serieFacturi tip="2" serieI="AFCT" nrI="1" nrF="1"/>
  <op1 tip="L" tip_partener="1" cota="21" cuiP="2000007" denP="CLIENT A SRL"
    nrFact="1" baza="10000" tva="2100"/>
  <op1 tip="A" tip_partener="1" cota="21" cuiP="2000015" denP="FURNIZOR B SRL"
    nrFact="1" baza="4000" tva="840"/>
</declaratie394>

3 — Correction: there is no rectificative XML shape. Re-compose the full declaration for the period (all operations, corrected + unchanged) and re-file it; it replaces the prior one. Most "corrections" are actually source-data fixes (a mistyped partner CUI, an uncleaned name) — fix the source, then re-file.

Special attention & gotchas

The pitfalls below trace either to direct XSD/validator verification (the control-sum formula, the serieFacturi requirement, the summary↔detail reconciliation, the CUI check digit and the rezumat2 incasari requirement were each observed against D394Validator.jar J8.0.2) or to an authoritative source (OPANAF 77/2022, the structure annex, and ANAF's discrepancy-notification procedure for the cross-declaration items). No uncorroborated practitioner claim is carried.

  • op_efectuate is the nil switch, and it must agree with the body. With op_efectuate="0" no detail may be introduced (and informatii counters are all zero); with op_efectuate="1" at least one operation must be present. A mismatch is a hard error.
  • totalPlata_A uses D394's own formula, nrCui1+…+nrCui4 + Σ rezumat2(bazaL+bazaA+bazaAI) — not D300's "sum of every numeric field". Recompute it whenever a partner or a rate-total changes; it is a checksum, not an amount owed.
  • Supplies force invoice-range sections (R112). As soon as one op1 has tip∈(L,LS,V), the declaration needs both a serieFacturi tip=1 (alocate) and a serieFacturi tip=2 (emise), and informatii.nrFacturi must then be >0. It is the most common "why won't my filled form validate" trap — the summaries and op1 can be perfect and it still fails on the missing series sections.
  • Summary and detail must reconcile exactly. The jar recomputes every rezumat1/rezumat2 aggregate as the sum over the matching op1 rows (bazaL = Σ op1.baza for tip=L, rezumat2.bazaA = Σ op1.baza for tip∈{A,C}, nrCui1 = COUNT(DISTINCT op1.cuiP), …). Author the op1 rows first and derive the summaries; never hand-key a summary that the detail does not support.
  • cuiP check digit and per-partner uniqueness. The XSD pattern is loose ([1-9]\d{1,9}) but the jar enforces the Romanian CUI check digit for tip_partener∈{1,2} (R218.2), and the combination (cuiP,tip,cota) must be unique across op1 — merge a partner's multiple invoices at the same rate into one row with nrFact>1. (The check-digit key is 753217532 applied right-aligned; a left-aligned key silently produces wrong-but-plausible CUIs that the jar rejects.)
  • The D394 ↔ D300 reconciliation is THE canonical ANAF cross-check. After each filing ANAF matches D394's per-rate totals against the filer's D300 and, by no later than the 5th of the month after the deadline, issues discrepancy/conformity notifications to filers whose numbers do not reconcile — and against counterparties' D394s (your declared sale to a partner should mirror their declared purchase from you) and against e-Factura / SAF-T (D406). Before filing, tie the sales journal to issued e-Factura and the per-partner totals to what will appear on D300. A notified discrepancy generally can't be "un-declared" — it is answered by letter to the tax office, so it is far cheaper to reconcile before filing.
  • tip_partener=2 (unregistered partners) needs the address block, not a CUI. When cuiP is null the partner-address fields (taraP, locP, judP, …) become required, judP is dropped for foreign taraP, and tip is limited to L,LS,N. tip_document is mandatory for tip_partener=2 with tip=N.
  • Reverse charge splits across op1/op11/detaliu. V/C operations carry no supplier VAT (tva null on the op1 row for V) and are broken down by product through op11.codPR and, in the summary, rezumat1/detaliu.bun. Cereals (bun=21) use CN product codes; every other anti-fraud category repeats its 2-digit bun code as codPR.
  • sistemTVA gates whole attribute families. Under cash accounting (sistemTVA=1) the tvaDed*/tvaDedAI*/tvaCol* families in informatii become populated; under the normal system (sistemTVA=0) they stay 0/absent.
  • Version- and rate-alignment trap (XSD wins over the annex). v5 is the only version with the 21/11 columns; older cached instructions describing 19%/9% rows predate Aug 2025. The structure annex itself is a redline document: it still lists struck-through attributes that no longer exist in v5 — the ASI operation type and most detaliu breakdown attributes (nrLiv, bazaLiv, nrAchiz, …) were removed, and its own sample even carries a leftover xmlns="…:v4" next to schemaLocation="…:v5". Trust the v5 XSD + the validator jar, not the annex's crossed-out rows.

v5 (current, retrieved 2026-07-17)

  • XSD: d394_20250917.xml (.xml extension), namespace mfp:anaf:dgti:d394:declaratie:v5, root declaratie394. The previous generation (v4, d394_20220510.xsd) was live 2022–2025; v5 adds the post-Aug-2025 VAT rates (21%/11% columns: tvaDedAI21, tvaDedAI11, BUN21, baza21, ... alongside the historic 24/20/19/9/5).
  • Shape: root carries ~28 header attributes; children: informatii (required, the per-declaration statistics block), then optional repeating rezumat1 (per partner-type × VAT-rate summaries), rezumat2 (per-rate totals, max 5), serieFacturi, lista (a closed 14-code CAEN list of cash-heavy sectors: bakery, car service, retail fuel, taxi, hotels, restaurants, bars, cleaning, fitness, hairdressing, ...), facturi, op1 (partner-level detail rows with full address fields), op2 (cash-register aggregates typed I1/I2).
  • Required root attributes: luna, an, tip_D394 (enum L/T/S/A — the filing periodicity), sistemTVA (0/1 — cash-accounting VAT), op_efectuate (0/1 — 0 means a nil declaration, and the empty informatii counters must then be all zero), cui, caen (full CAEN enumeration in-XSD), den, adresa, telefon (required here, unlike D300 where it is optional), totalPlata_A, representative block (denR, functie_reprez, adresaR), preparer block (tip_intocmit 0/1, den_intocmit, cif_intocmit), optiune (0/1 consent to publish), prsAfiliat (0/1).
  • Preparer conditional rule (the one non-obvious cross-check on a nil form) — rule R30: if tip_intocmit = 0, or tip_intocmit = 1 with functie_intocmit empty, then calitate_intocmit must be filled. So a self-prepared declaration needs calitate_intocmit even though the XSD marks it optional.
  • informatii has 21 required attributes — counters and statistics (nrCui1–nrCui4, nr_BF_i1, incasari_i1/2, nrFacturi*, tvaDedAI* per rate, solicit) — all 0 on a nil declaration.
  • totalPlata_A is the control sum again (0 on a nil form; on filled forms let DUK's rule message dictate the value, as on D300/D390).
  • cui check digit enforced by the jar (XSD pattern alone is loose).
  • Minimal valid instance (nil declaration, June 2026, monthly):
<?xml version="1.0" encoding="UTF-8"?>
<declaratie394 xmlns="mfp:anaf:dgti:d394:declaratie:v5"
  luna="6" an="2026" tip_D394="L" sistemTVA="0" op_efectuate="0"
  cui="1234565" caen="6201" den="EXEMPLU TEST SRL"
  adresa="Mun. Bucuresti, Str. Exemplu nr. 1" telefon="0211234567"
  totalPlata_A="0"
  denR="Popescu Ion" functie_reprez="Administrator"
  adresaR="Mun. Bucuresti, Str. Exemplu nr. 1"
  tip_intocmit="0" calitate_intocmit="Administrator"
  den_intocmit="Popescu Ion" cif_intocmit="1234565"
  optiune="0" prsAfiliat="0">
  <informatii nrCui1="0" nrCui2="0" nrCui3="0" nrCui4="0" nr_BF_i1="0"
    incasari_i1="0" incasari_i2="0" nrFacturi_terti="0" nrFacturi_benef="0"
    nrFacturi="0" nrFacturiL_PF="0" nrFacturiLS_PF="0" val_LS_PF="0"
    tvaDedAI24="0" tvaDedAI21="0" tvaDedAI11="0" tvaDedAI20="0" tvaDedAI19="0"
    tvaDedAI9="0" tvaDedAI5="0" solicit="0"/>
</declaratie394>

The stale-jar trap (worth repeating here)

update5/D394/D394Validator.jar (the unversioned directory) serves the 2012 first release, which demands namespace v1 (the pre-2016 simple D394) for every period and rejects the entire modern structure. The feed's real JURL is update5/D394_31/D394Validator.jar (J8.0.2). If DUK claims the correct namespace is …:v1, the installed jar is stale — reinstall from the feed's JURL before touching the XML.