Skip to content

D301 — special VAT return (decont special de TVA)

The decont special de taxă pe valoarea adăugată is the pay-only VAT return for persons who are not registered for VAT under art. 316 of the Fiscal Code but who nonetheless owe Romanian VAT on specific operations (intra-EU acquisitions, received reverse-charge services, and similar). This file is a completion guide: what the declaration settles, who files it and when, and how each form section maps onto the XSD attribute anafpy authors — followed by the technical XSD/DUK layer. ANAF's validator jar (D301Validator.jar) and published instructions are the authority; this guide is a distilled bridge, not a re-implementation of the rules. Everything below the "Common scenarios" instances was proven hands-on on 2026-07-17 against D301Validator.jar J1.2.5 (feed directory D301_9, UniversalCode D301_A2.0.0).

Unlike the D300 decont, D301 has no deduction side — it is a pure declaration-and-payment of the VAT the filer owes as the person liable to pay, because the filer is outside the ordinary art. 316 VAT system and so cannot deduct through a normal decont. It exists to collect the VAT that Romania is owed on cross-border operations by small enterprises, art. 317-registered persons, and non-taxable legal persons. Each operation is self-assessed (base × exchange rate × VAT rate) and the total is a titlu de creanță — a payment obligation effective from the filing date.

  • Current model: approved by OPANAF 592/2016 (M.Of. 94/08.02.2016), used since the January 2016 reporting period (art. 5 of the order). The legal basis for the return is art. 324 of the Fiscal Code (Legea 227/2015); the substantive liability articles are art. 307 (person liable to pay) and the intra-EU-acquisition rules of art. 268/126. The model has been technically stable since 2016: the last validator change (J1.2.5, Oct 2020) only widened the nr_doc field.
  • Rates are not encoded in the form. D301 has no per-rate rows (contrast D300's Rd.9/Rd.10/Rd.11). The filer computes the VAT due at whatever rate applies to the operation and enters the resulting tva amount per document. As a result the Aug-2025 21% / 11% rate change did not touch the D301 XSD, jar, or annex — the version-alignment trap that bites the rate-row forms does not apply here. Apply the current standard rate (21% since 1 Aug 2025) when self-assessing, but nothing in the schema hard-codes it.
  • Periodicity: not periodic. D301 is filed only for a reporting month in which the tax on a qualifying operation becomes chargeable — there is no nil filing and no fixed monthly obligation.

Who files & when

  • Who: taxable persons and non-taxable legal persons who are not registered (and not required to register) for VAT under art. 316, but who owe Romanian VAT. Two sub-populations, distinguished by pers_inreg:
  • art. 317-registered (pers_inreg="2") — small enterprises under the art. 310 exemption regime, persons making only exempt-without-credit supplies (art. 292), and non-taxable legal persons, all registered under art. 317 only for intra-EU acquisitions / services. Their fiscal code carries an RO prefix on paper (only this group prefixes RO).
  • not VAT-registered at all (pers_inreg="1") — e.g. a private individual buying a new means of transport from another Member State, who registers nothing but still owes the VAT before plating the vehicle.
  • Sections correspond to the reason you owe VAT (see the tip_operatie mapping below): intra-EU acquisitions of goods (S1), of new means of transport (S2), of excise goods (S3), operations under art. 307(2)/(3)/(5)/(6) such as received reverse-charge services and gas/electricity supplies (S4), and the intra-EU-services breakout of S4 (S4.1).
  • Deadline: the 25th inclusive of the month following the month in which the tax on the operation became chargeable — for sections 1, 3, 4 and 4.1. Corroborated by two independent sources: OPANAF 592/2016 anexa 2 point II, and the practitioner/administrative guidance (fiscalitatea.ro, ANAF Brașov). A new means of transport (S2) has a stricter deadline: before the vehicle is registered (plated) in Romania, but no later than the 25th of the following month.
  • Corrections: D301 is rectifiable, unlike D300. A correction is a full re-file of the same reporting period with d_rec="1" (there is no delta document). For new means of transport, several D301 for the same month are allowed without ticking rectificative (each vehicle can be its own filing).
  • Relationship to D390. The intra-EU acquisitions declared in D301 sections 1–3 are the same operations reported on the recapitulative statement D390. The instructions deliberately align the two on the chargeability moment (the invoice date under art. 222 of Directive 2006/112/EC, or the 15th of the following month) so the D301 base and the D390 total reconcile — a mismatch is a standard ANAF cross-check.

Filling guide

The document is one <declaratie301> element carrying the header on its attributes, plus up to 4000 <sectiune> child rows (one per document). This is the structural difference from D300, which has no children.

Header ↔ detail contract. The header carries five table totals baza1/tva1 … baza5/tva5, one pair per form section; all ten are required even when zero. Each non-zero total must equal the sum of its backing <sectiune> rows (rule R18/R19 and analogues). Amounts are decimals (2 places) — unlike the integer-RON forms D300/D100.

Identification & header block (required attributes)

Attribute Form field Notes
luna Perioada de raportare — luna reporting month 1–12
an Perioada de raportare — an reporting year (XSD accepts 2013–2100)
d_rec Declarație rectificativă 0 initial / 1 rectifying (full re-file)
mijl_trans Achiziții IC de mijloace de transport noi 0/1; set 1 whenever a section-2 row is present — also drives nr_evid position 18
temei Temei legal 0 ordinary / 1 art. 105(6)(a) / 2 art. 105(6)(b); on an initial filing (d_rec="0") it must not be 1 (rule R5b)
cif Cod de identificare fiscală company CF or a 13-digit CNP for a natural person; check digit enforced by the jar
denumire Denumire / Nume, Prenume required (≤ 200)
adresa Domiciliul fiscal optional (≤ 1000)
telefon / fax / email contact optional
banca / cont Banca / Contul required; no , or #
pers_inreg registration status 1 = not VAT-registered; 2 = registered under art. 317 (IC acquisitions only)
nr_evid Nr. de evidență a plății 23 chars; position 18 mirrors mijl_trans; checksum-verified
baza1…baza5 / tva1…tva5 per-section totals all ten required; each = sum of matching <sectiune> rows
totalPlata_A Suma de control control sum, not the amount payable
nume_declarant / prenume_declarant / functia_declarant declarant required

Sections → tip_operatie (which table you owe under)

tip_operatie Form section Operations
1 Secțiunea 1 IC acquisitions of goods (other than new transport / excise); includes triangular operations where you are liable under art. 307(4). art. 317 persons
2 Secțiunea 2 IC acquisitions of NEW means of transport — anyone not registered under art. 316, art. 317 or not
3 Secțiunea 3 IC acquisitions of excise goods
4 Secțiunea 4 Operations under art. 307(2)/(3)/(5)/(6): received services with place of supply in RO (reverse charge), gas/electricity supplied by a non-established person, goods leaving special regimes, other supplies by non-established persons
5 Secțiunea 4.1 IC services where the beneficiary owes VAT under art. 307(2) — the intra-EU-services breakout of section 4 (every S4.1 row must also appear as an S4 row; rule R32)

<sectiune> detail row (all attributes required)

Attribute Form column Notes
tip_operatie (which section) 1–5
nr_doc col.1 Document — Număr invoice or self-invoice number; XSD/annex say max 20, but jar J1.2.5 accepts up to 50
data_doc col.1 Document — Data dotted ZZ.LL.AAAA
val_valuta col.2 Valoare în valută currency amount (2 decimals)
tip_valuta col.3 Tip valută closed 20-currency ISO list (incl. RON for a lei-invoiced operation)
curs_valutar col.4 Curs de schimb BNR/bank rate at chargeability (4 decimals, > 0)
baza col.5 Baza de impozitare taxable base (guidance: val_valuta × curs_valutar; not jar-enforced — the annex formula is struck through)
tva col.6 TVA datorat baza × the applicable VAT rate

Control sum. totalPlata_A = INT(baza1+…+baza5 + tva1+…+tva5) — the integer truncation of the ten header totals. Section amounts do not enter it (they are already rolled into the totals). It is a checksum, not the amount to pay; the amount actually owed is the sum of the tva* totals.

Common scenarios

Each instance below validated clean (ok) against D301Validator.jar J1.2.5 on 2026-07-17. nr_evid is composed for a June-2026 reporting month (10 301 01 0626 250726 …); the synthetic cif="1234565" is a check-digit-valid CF and cif="1800101010015" is a check-digit-valid CNP.

1 — Intra-EU acquisition of goods (section 1, art. 317 person). Two received invoices, VAT self-assessed at 21%. Note temei="0" (ordinary filing) and mijl_trans="0" → nr_evid position 18 is 0:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie301 xmlns="mfp:anaf:dgti:d301:declaratie:v1"
  luna="6" an="2026" d_rec="0" mijl_trans="0" temei="0"
  cif="1234565" denumire="EXEMPLU TEST SRL"
  banca="Banca Exemplu" cont="RO49AAAA1B31007593840000" pers_inreg="2"
  nr_evid="10301010626250726000042"
  baza1="12430" tva1="2610.30" baza2="0" tva2="0" baza3="0" tva3="0"
  baza4="0" tva4="0" baza5="0" tva5="0" totalPlata_A="15040"
  nume_declarant="Popescu" prenume_declarant="Ion" functia_declarant="Administrator">
  <sectiune tip_operatie="1" nr_doc="F2026-001" data_doc="10.06.2026"
    val_valuta="2000" tip_valuta="EUR" curs_valutar="4.9700" baza="9940" tva="2087.40"/>
  <sectiune tip_operatie="1" nr_doc="F2026-002" data_doc="20.06.2026"
    val_valuta="500" tip_valuta="EUR" curs_valutar="4.9800" baza="2490" tva="522.90"/>
</declaratie301>

2 — New means of transport (section 2, private individual). A natural person buys a new car from Germany. mijl_trans="1", cif is a CNP, pers_inreg="1". Because mijl_trans="1", nr_evid position 18 is 1 (…250726 1 00043) — the checksum changes accordingly:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie301 xmlns="mfp:anaf:dgti:d301:declaratie:v1"
  luna="6" an="2026" d_rec="0" mijl_trans="1" temei="0"
  cif="1800101010015" denumire="POPESCU ION"
  banca="Banca Exemplu" cont="RO49AAAA1B31007593840000" pers_inreg="1"
  nr_evid="10301010626250726100043"
  baza1="0" tva1="0" baza2="124250" tva2="26092.50" baza3="0" tva3="0"
  baza4="0" tva4="0" baza5="0" tva5="0" totalPlata_A="150342"
  nume_declarant="Popescu" prenume_declarant="Ion" functia_declarant="Proprietar">
  <sectiune tip_operatie="2" nr_doc="DE-2026-77" data_doc="12.06.2026"
    val_valuta="25000" tip_valuta="EUR" curs_valutar="4.9700" baza="124250" tva="26092.50"/>
</declaratie301>

3 — Received intra-EU service, reverse charge (sections 4 + 4.1). A €1 000 consulting service self-assessed at 21%. The same operation is entered twice: once as a section-4 row (tip_operatie="4") and once as its 4.1 breakout (tip_operatie="5") — rule R32 requires the mirror. Add to the header baza4="5000" tva4="1050" baza5="5000" tva5="1050" with totalPlata_A="12100":

  <sectiune tip_operatie="4" nr_doc="SRV-88" data_doc="10.06.2026"
    val_valuta="1000" tip_valuta="EUR" curs_valutar="5.0000" baza="5000" tva="1050"/>
  <sectiune tip_operatie="5" nr_doc="SRV-88" data_doc="10.06.2026"
    val_valuta="1000" tip_valuta="EUR" curs_valutar="5.0000" baza="5000" tva="1050"/>

Special attention & gotchas

The pitfalls below trace either to direct XSD/validator verification (each rule id — R5b, R16, R18, R28, R32 — and the temei / nr_doc behaviours were observed against D301Validator.jar J1.2.5 on 2026-07-17) or to an authoritative source (OPANAF 592/2016 for the who-files categories, the section semantics, and the deadlines). No uncorroborated practitioner claim is carried.

  • nr_evid position 18 is a mijl_trans flag, not part of a fixed 0000. This is the D301-specific twist. In D300 positions 18–21 are the constant 0000; in D301 position 18 is 0 when mijl_trans="0" and 1 when mijl_trans="1" (positions 19–21 stay 000). Filing a section-2 (new transport) return with a D300-style nr_evid fails rule R16 ("necorelare între R5 (mijl_trans) și nr. de evidența a plății"). Compose it with special_vat_evidence_number(month, year, new_transport=...) (MCP: declaratie_nr_evid with form="D301", mijl_trans), which sets position 18 from the flag and recomputes the checksum — do not reuse the D300 payment_evidence_number (it fixes positions 18–21 at 0000, valid only for mijl_trans="0").
  • temei="0" is the ordinary value — and the XSD is wrong about it. The XSD types temei as IntInt1_2SType (min 1, max 2), but the validator accepts temei="0" ("neither art. 105 ground checked") and that is the correct value for a routine filing. temei="1" (art. 105(6)(a)) is forbidden on an initial declaration (d_rec="0"; rule R5b) and temei="2" (art. 105(6)(b)) asserts a filing after annulment of the verification reserve. The jar wins over the XSD: use temei="0" unless you are actually filing under art. 105(6).
  • nr_doc accepts up to 50 characters, though the XSD and annex say 20. The jar J1.2.5 (Oct 2020) widened nr_doc to 50, but the published XSD (d301_20200130.xsd, Jan 2020, Str20) and the 2016 structure annex (C(20)) were never re-aligned. A 30-character nr_doc validates clean. The jar is the authority — but authoring to the XSD's 20-char limit is the safe subset.
  • Every table total must be backed by its section rows. Rules R18/R19 (and the analogues for tables 2–5) check bazaN/tvaN against the sum of the <sectiune> rows with that tip_operatie. A header total with no matching rows fails with "baza1 (9999) diferit de suma(baza1) (1000.0)" (rule R18).
  • Section 4.1 must be contained in section 4. A tip_operatie="5" (S4.1) row with no matching tip_operatie="4" (S4) row fails rule R32 ("Există 1 secțiuni 4.1 și doar 0 secțiuni 4, care ar trebui să conțină secțiunile 4.1"). Intra-EU services owed under art. 307(2) are reported in both tables: as a section-4 operation and again as its 4.1 breakout. The "S4 = S4.1 + S4.2" formula printed on the 2016 annex is struck through — the enforced rule is the containment above, not an additive equality.
  • totalPlata_A is a control sum, not the amount to pay. Rule R28 requires totalPlata_A = INT(baza1+…+baza5 + tva1+…+tva5); a wrong value fails with "totalPlata_A (9999) = totalPlata_A calculat conform regulii (1210)". The amount actually owed to the budget is the sum of the tva* totals.
  • baza per row is free input, not a forced product. The 2016 annex prints baza = round(val_valuta × curs_valutar, 0) but struck through; the jar does not enforce it (and baza carries 2 decimals). Compute the base per the instructions (col.2 × col.4) but the validator will not re-derive it — enter the amount you intend.
  • cif is a CNP or a company CF, and the jar checks the digit. The XSD pattern [1-9]\d{12}|[1-9]\d{1,9} admits a 13-digit CNP (natural person) or a 2–10-digit CF; the validator additionally enforces the CNP/CF check digit. Synthetic data needs a checksum-valid identifier — 1234565 (CF) and 1800101010015 (CNP) both pass.
  • Paper form vs XML: nr_evid is required in the file though the form says "leave blank." The 2016 paper instructions (anexa 2, point 3) say the Nr. de evidența a plății box is not completed. The electronic XML nonetheless requires nr_evid (XSD use="required", checksum-verified) — a wire-vs-paper discrepancy. Compose it (with the position-18 rule above), never leave it out of the XML.

v1 (current; XSD d301_20200130.xsd, jar J1.2.5)

  • Namespace mfp:anaf:dgti:d301:declaratie:v1, root declaratie301 — for once, the published XSD matches the live wire format.
  • Shape: flat header + up to 4000 sectiune document-detail rows. Header carries five table totals baza1/tva1 … baza5/tva5 — all ten are required even when zero. Amounts are decimals (2 decimal places), unlike the integer-RON forms (D300/D100).
  • Each non-zero table total must be backed by detail rows: rules R18/R19 check bazaN/tvaN against suma(bazaN) over the sectiune rows with tip_operatie="N" (tables 1–5). A total without matching sections fails with "baza1 (1000) diferit de suma(baza1) (0.0)".
  • sectiune (all attributes required): tip_operatie (1–5), nr_doc, data_doc (dotted date), val_valuta, tip_valuta (20-currency ISO list — includes RON), curs_valutar (4 decimals), baza, tva — i.e. per-document foreign-currency detail is mandatory.
  • temei conditional rule (R5b): on an initial declaration (d_rec="0"), temei must not be 1 (1 is reserved for the rectifying ground). Use 0 — the ordinary value, accepted by the jar despite the XSD's 1–2 range — unless actually filing under art. 105(6)(b), which is what 2 asserts; see the gotcha above.
  • totalPlata_A control sum counts only the header totals (rule R28 states the computed value; sectiune amounts are not added — 1000+210 → 1210 in the sample).
  • nr_evid: 10 301 01 MMYY DDMMYY <mijl_trans> 000 <check> — code 301, the 25th-of-next-month due date, position 18 = mijl_trans. Composed by anafpy.declaratii.special_vat_evidence_number. For mijl_trans="0" the D300 monthly number happens to coincide (code 301, position 18 0), but the D301 composer is what sets position 18 for a new-transport filing.
  • pers_inreg (1/2) is the art. 316/317 registration status; mijl_trans flags new-transport-means operations.
  • Minimal valid instance (one 1000 RON intra-EU acquisition at 21%, June 2026):
<?xml version="1.0" encoding="UTF-8"?>
<declaratie301 xmlns="mfp:anaf:dgti:d301:declaratie:v1"
  luna="6" an="2026" d_rec="0" mijl_trans="0" temei="0"
  cif="1234565" denumire="EXEMPLU TEST SRL"
  banca="Banca Exemplu" cont="RO49AAAA1B31007593840000" pers_inreg="2"
  nr_evid="10301010626250726000042"
  baza1="1000" tva1="210" baza2="0" tva2="0" baza3="0" tva3="0"
  baza4="0" tva4="0" baza5="0" tva5="0"
  totalPlata_A="1210"
  nume_declarant="Popescu" prenume_declarant="Ion" functia_declarant="Administrator">
  <sectiune tip_operatie="1" nr_doc="F123" data_doc="15.06.2026"
    val_valuta="200" tip_valuta="EUR" curs_valutar="5.0000"
    baza="1000" tva="210"/>
</declaratie301>