D300 — VAT return (decont de TVA)

Monthly/quarterly VAT return. This file is a completion guide: what the declaration settles, who files it and when, and how each form row maps onto the XSD attribute anafpy authors — followed by the technical XSD/DUK layer. ANAF's validator jar (D300Validator.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 J12.0.1 (XSD v12).

Purpose & legal basis

The decont de taxă pe valoarea adăugată is the periodic self-assessment of VAT: it sets output VAT collected on supplies against input VAT deductible on purchases and yields the net VAT payable or the negative amount (VAT credit) carried forward or refunded. It is filed by every taxable person registered for VAT under art. 316 of the Fiscal Code (Legea 227/2015), declaring the tax per art. 323 of the Fiscal Code (the article that governs the decont itself).

• Current model: approved by OPANAF 174/2026 (M.Of. 105/09.02.2026), used from the first fiscal period of 2026. It implements Legea 141/2025 (fiscal-budgetary measures) — the reason the standard rate row carries 21% (Rd.9), the reduced row 11% (Rd.10), and a transitory 9% (Rd.11). The 9% row is narrow: it covers the reduced rate kept transitorily until 31 July 2026 for the supply of housing to natural persons (art. III of Legea 141/2025). The new model dropped the old 19% and 5% rows entirely. The immediate predecessor, OPANAF 2131/2025 (Aug 2025), introduced the 21% / 11% rates; a cached pre-Aug-2025 instructions PDF describing 19% / 9% rows would silently poison the mapping — see Special attention & gotchas.
• Periodicity: monthly is the default fiscal period. The reporting period is carried by tip_decont + luna/an (see the mapping below), not by a rectificative flag.

Who files & when

• Who: persons registered for VAT purposes under art. 316 Fiscal Code file a D300 for every fiscal period, including nil periods (a period with no operations still requires a decont — see the nil scenario).
• Deadline: the 25th (inclusive) of the month following the reporting period — the 25th of the next month for monthly filers, the 25th of the month after the quarter for quarterly filers, the 25th of the first month of the following semester for S, and 25 January for the annual A decont.
• Monthly vs quarterly election: the fiscal period is the calendar quarter for a taxpayer whose prior-year turnover did not exceed €100,000 and who made no intra-EU acquisition of goods. Any intra-EU acquisition of goods (no value threshold) forces the fiscal period to the calendar month for the rest of the year; the switch is notified with a D092. tip_decont must agree with the elected period and luna: T decont months are the quarter-closing months 03/06/09/12 (a special mid-quarter filing exists only for the intra-EU-acquisition switch case — the structure annex spells out the exact tip_decont↔luna matrix).
• Corrections: D300 has no rectificative checkbox — there is no classic "declarație rectificativă" for the decont. Errors from prior periods are corrected through the regularization rows of the current decont (Rd.16 collected / Rd.32 deducted; see the pitfalls), or the negative-amount carry-forward. Material errors (a wrong period, a wrong CUI, and similar) follow a separate procedure at the tax office (correction request / D700), not a regularization row. temei (0 or 2) flags the narrow case of a decont filed after annulment of the verification reserve (art. 105(6)(b) of the Fiscal Procedure Code); ordinary declarations use temei="0".

Filling guide

The document is one empty XML element — everything is an attribute on <declaratie300>, no children. There are two kinds of attribute: the identification block (25 required attributes) and the numeric rows (R…_1 / R…_2 pairs, all optional, default absent = zero).

The two-column model. Each substantive form row has a base column (col.1, attribute suffix _1) and a VAT column (col.2, suffix _2). R9_1 is "Rd.9 col.1" (the taxable base of the 21% supplies) and R9_2 is "Rd.9 col.2" (the VAT on them). Exempt/informative rows have only a _1. The form is split into two halves — collected/output VAT (Rd.1–Rd.19) totalling at R17_*, and deductible/input VAT (Rd.20–Rd.30) totalling at R27_* — followed by the settlement cascade (Rd.35–Rd.45) that nets them.

Attribute names are stable; the rate each carries is not. ANAF kept the attribute names across the VAT-rate change but re-pointed them: in v12 R9 is the 21% row (was 19%), R10 is 11% (was 9%), R11 is 9% (art. III Legea 141/2025; was 5%). Always read the rate from the current structure annex, never from the attribute number.

Identification block (required attributes)

Attribute	Form field	Notes
luna	Perioada de raportare — luna	reporting month 1–12
an	Perioada de raportare — an	reporting year (≥ 2025 for v12 rules)
depusReprezentant	Decont consolidat depus de reprezentantul grupului fiscal	0/1
bifa_interne	Metoda simplificată pentru operațiuni interne	0/1 — see pitfalls
temei	Temeiul legal (decont după anularea rezervei verificării)	enum 0 or 2
cuiSuccesor	Codul de identificare al succesorului	optional; CUI-validated
nume_declar / prenume_declar / functie_declar	Nume / Prenume / Funcție declarant	required text
cui	Cod de înregistrare în scopuri de TVA	CUI check-digit enforced by the jar
den	Denumire / Nume și Prenume	required
adresa	Adresă domiciliu fiscal	required
telefon / fax / mail	contact	optional
banca / cont	Banca / Contul	required; no , or #
caen	Cod CAEN	closed enum (Rev.2 and Rev.3 accepted)
tip_decont	Tip decont	enum L/T/S/A (lunar/trimestrial/semestrial/anual)
pro_rata	Pro-rata	0–100; 100 is the safe default
bifa_cereale / bifa_mob / bifa_disp / bifa_cons	reverse-charge sector checkboxes	D/N — cereals art.160; phones/devices/consoles art.331
solicit_ramb	Solicitare rambursare TVA	D/N — see pitfalls
nr_evid	Nr. de evidență a plății	23 chars, checksum; compose with payment_evidence_number
totalPlata_A	Suma de control	control sum, not the amount payable — see pitfalls

Output (collected) VAT rows → attributes

Attr (base / VAT)	Rd.	Field
R1_1	1	Livrări intracomunitare de bunuri, scutite art.294(2)a,d
R2_1	2	Regularizări livrări intracomunitare scutite
R3_1	3	Livrări/prestări cu locul în afara RO + livrări IC scutite art.294(2)b,c
R3_1_1	3.1	Prestări IC care nu beneficiază de scutire în statul membru
R4_1	4	Regularizări prestări IC nescutite
R5_1 / R5_2	5	Achiziții intracomunitare de bunuri (taxare inversă)
R5_1_1 / R5_1_2	5.1	…furnizor înregistrat în statul membru de plecare
R6_1 / R6_2	6	Regularizări achiziții IC de bunuri
R7_1 / R7_2	7	Achiziții de bunuri (altele) + servicii cu taxare inversă
R7_1_1 / R7_1_2	7.1	…achiziții IC de servicii
R8_1 / R8_2	8	Regularizări achiziții IC de servicii
R9_1 / R9_2	9	Livrări taxabile cu cota 21%
R10_1 / R10_2	10	Livrări taxabile cu cota 11%
R11_1 / R11_2	11	Livrări taxabile cu cota 9% — transitory (housing to natural persons, until 31 Jul 2026; art. III Legea 141/2025)
R12_1 / R12_2	12	Achiziții cu taxare inversă (simplificare, domestic); subrows R12_1_* (21%), R12_2_* (11%)
R13_1	13	Livrări supuse măsurilor de simplificare
R14_1	14	Livrări scutite fără drept de deducere (altele decât rd.1–3)
R15_1	15	Livrări scutite fără drept de deducere
R16_1 / R16_2	16	Regularizări taxă colectată (corrections)
R64_1 / R64_2	17	Vânzări IC la distanță + servicii TBE cu locul în RO (art. 278¹(1))
R65_1 / R65_2	18	Regularizări vânzări la distanță
R17_1 / R17_2	19	TOTAL TAXĂ COLECTATĂ — computed

R17_1 = R1_1+R2_1+R3_1+R4_1+R5_1+R6_1+R7_1+R8_1+R9_1+R10_1+R11_1+R12_1+R13_1+R14_1+R15_1+R16_1+R64_1 (subrows 3.1/5.1/7.1/… excluded); R17_2 sums the matching _2 columns (R5_2+R6_2+R7_2+R8_2+R9_2+R10_2+R11_2+R12_2+R16_2+R64_2).

Deductible (input) VAT rows → attributes

Attr (base / VAT)	Rd.	Field
R18_1 / R18_2	20	Achiziții IC de bunuri, taxare inversă — = Rd.5 (R5)
R18_1_1 / R18_1_2	20.1	…furnizor înregistrat — = Rd.5.1
R19_1 / R19_2	21	Regularizări achiziții IC bunuri — = Rd.6
R20_1 / R20_2	22	Achiziții bunuri/servicii cu taxare inversă — = Rd.7
R20_1_1 / R20_1_2	22.1	…achiziții IC servicii — = Rd.7.1
R21_1 / R21_2	23	Regularizări achiziții IC servicii — = Rd.8
R22_1 / R22_2	24	Achiziții taxabile cu cota 21%
R23_1 / R23_2	25	Achiziții taxabile cu cota 11%
R25_1 / R25_2	27	Achiziții cu taxare inversă (simplificare) — = Rd.12; subrows R25_1_*, R25_2_*, R25_3_1
R26_1 / R26_1_1	28/28.1	Achiziții scutite/neimpozabile (informative)
R43_2	—	Compensația în cotă forfetară (produse agricole)
R44_2	—	Regularizări compensație cotă forfetară
R27_1 / R27_2	30	TOTAL TAXĂ DEDUCTIBILĂ — computed

R27_1 = R18_1+R19_1+R20_1+R21_1+R22_1+R23_1+R25_1; R27_2 = R18_2+R19_2+R20_2+R21_2+R22_2+R23_2+R25_2+R43_2+R44_2.

Settlement cascade (all computed — the jar enforces every formula)

Attr	Rd.	Meaning	Formula
R28_2	31	Sub-total taxă dedusă (art.297/298/300 + compensație)	≤ R27_2
R32_2	35	TOTAL TAXĂ DEDUSĂ	R28_2+R29_2+R30_2+R31_2
R33_2	36	Sumă negativă a TVA în perioadă	MAX(R32_2 − R17_2, 0)
R34_2	37	Taxă de plată în perioadă	MAX(R17_2 − R32_2, 0)
R35_2	38	Sold TVA de plată din decontul precedent neachitat	0 if R38_2 > 0
R36_2	39	Diferențe de plată stabilite de inspecție	input
R37_2	40	TVA de plată cumulat	R34_2+R35_2+R36_2
R38_2	41	Sold negativ reportat din perioada precedentă	0 if R35_2 > 0
R39_2	42	Diferențe negative stabilite de inspecție	input
R40_2	43	Sumă negativă a TVA cumulată	R33_2+R38_2+R39_2
R41_2	44	Sold TVA de plată la sfârșitul perioadei	MAX(R37_2 − R40_2, 0)
R42_2	45	Sold negativ la sfârșitul perioadei	MAX(R40_2 − R37_2, 0)

At most one of R41_2 (pay this) and R42_2 (credit to carry/refund) is non-zero. The informative annex attributes at the tail (nr_facturi, baza, tva, nr_facturi_primite, baza_primite, tva_primite; valoare_a…/tva_a… for the cash-accounting system; valoare_b…/tva_b… for non-deducted acquisitions; total_precedent/total_curent for distance sales) are statistics ANAF asks for alongside the settlement; they do not feed the cascade but do count toward totalPlata_A.

Common scenarios

Each instance below validated clean (ok) against D300Validator.jar J12.0.1 on 2026-07-17. All use nr_evid for a monthly (L) June-2026 decont, computed with payment_evidence_number(tip_decont="L", month=6, year=2026); the synthetic cui="1234565" is check-digit valid. totalPlata_A is the sum of every filled numeric attribute (rule R26 recomputes it each time you add a field).

1 — Nil return (a period with no operations). Only the identification block; every row absent; totalPlata_A="0".

<?xml version="1.0" encoding="UTF-8"?>
<declaratie300 xmlns="mfp:anaf:dgti:d300:declaratie:v12"
  luna="6" an="2026" depusReprezentant="0" bifa_interne="0" temei="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  banca="Banca Exemplu" cont="RO49AAAA1B31007593840000"
  caen="6201" tip_decont="L" pro_rata="100"
  bifa_cereale="N" bifa_mob="N" bifa_disp="N" bifa_cons="N" solicit_ramb="N"
  nr_evid="10301010626250726000042" totalPlata_A="0"/>

2 — Typical VAT-payable month: 10 000 lei of 21% domestic sales (R9) and 4 000 lei of purchases with 840 lei deductible VAT (R22). Collected 2 100 − deducted 840 = 1 260 payable (R34_2 → R37_2 → R41_2). Add to the identification block:

  R9_1="10000" R9_2="2100"
  R17_1="10000" R17_2="2100"
  R22_1="4000" R22_2="840"
  R27_1="4000" R27_2="840"
  R28_2="840" R32_2="840"
  R34_2="1260" R37_2="1260" R41_2="1260"

with totalPlata_A="39340".

3 — Intra-EU acquisition of goods (the mirror-rule case): a 5 000 lei intra-EU acquisition self-assessed at 21% (1 050 lei) plus the same 10 000 lei domestic 21% sale. The acquisition appears on both halves with equal values — collected R5 and deducted R18 (rules V_7/V_8 force R18 = R5):

  R5_1="5000" R5_2="1050"
  R9_1="10000" R9_2="2100"
  R17_1="15000" R17_2="3150"
  R18_1="5000" R18_2="1050"
  R27_1="5000" R27_2="1050"
  R28_2="1050" R32_2="1050"
  R34_2="2100" R37_2="2100" R41_2="2100"

with totalPlata_A="56800". (Note: with an intra-EU acquisition the fiscal period is monthly, so tip_decont="L" is correct here.)

Special attention & gotchas

The pitfalls below trace either to direct XSD/validator verification (the control sum, the reverse-charge mirror rules, the bifa_interne exclusion, and the rate-coherence warnings were each observed against D300Validator.jar J12.0.1) or to an authoritative source (OPANAF 174/2026 and the ANAF RO e-TVA brochure for the regularization, refund, and cross-declaration items). No uncorroborated practitioner claim is carried.

• totalPlata_A is a control sum, not the amount to pay. Rule R26 requires it to equal the arithmetic sum of every filled numeric attribute (rows + informative annex fields). The amount actually owed is R41_2. An all-zero return has totalPlata_A="0".
• Reverse-charge and intra-EU acquisitions are self-assessed on both sides. The validator enforces equality between the collected and deductible legs: R18=R5, R18_1=R5_1, R19=R6, R20=R7, R20_1=R7_1, R21=R8, R25_1=R12_1 (rules V_7–V_19). Fill only one leg and it fails.
• bifa_interne="1" (simplified method for internal operations) forbids the intra-EU / reverse-charge rows. Rule V_1: with bifa_interne=1, the whole set R1_1, R2_1, R3_1, R3_1_1, R4_1, R5_*, R6_*, R7_*, R8_*, R18_*, R19_*, R20_*, R21_*, R26_1_1 must be null. The default for an ordinary SME is bifa_interne="0".
• Old-rate regularizations have no dedicated row — the 2026 trap. The new model dropped the 19% / 5% rows, but corrections that touch old-rate operations still happen (e.g. an advance invoiced at 19% storno-ed and re-invoiced at 21% on the final invoice). Per OPANAF 174/2026, Rd.16 "regularizări taxă colectată" (R16_*) absorbs the amounts from correcting rows 9–12 of prior deconts plus the taxable-base adjustments of art. 287 Fiscal Code; the deducted side mirrors this at Rd.32 (R30_*). So a 19%→21% advance correction splits: the reversal rides the regularization row, the fresh supply rides the current-rate row (Rd.9). Do not look for a 19% row — there isn't one.
• solicit_ramb="D" (request a refund) starts the refund-resolution procedure (with a possible anticipated control above certain thresholds), and once ticked the negative amount is no longer carried forward to the next decont. It is allowed only when the closing negative balance R42_2 is < 5 000 lei — otherwise use N and carry the credit forward (many filers carry small credits forward rather than trigger the procedure).
• What does NOT go in the decont. Operations outside the scope of VAT (damages/penalties, dividends, salaries) are not reported. Under cash accounting (TVA la încasare), VAT becomes exigible on collection, not on invoice: collect in the decont of the period you are paid, and deduct only when you pay a supplier who is himself on cash accounting. The rate to apply is the rate at the invoice date, not at the collection date — a frequent error at a rate-transition boundary.
• Cross-declaration and RO e-TVA correlations are the real filing risk, not the arithmetic. ANAF's pre-filled RO e-TVA decont shares D300's structure and is reconciled automatically against e-Factura and SAF-T (D406); mismatches above the significance threshold generate conformity notifications you must answer. Before filing, the sales journal should tie to issued e-Factura, the purchase journal to received invoices, and per-partner totals to D394 (domestic) and D390 (intra-EU). The reverse-charge mirror rules above are the same coherence, enforced inside the decont.
• VAT-rate coherence is a warning (A:/atentionare), not an error. Rule R47 flags R9_2 outside [20% · R9_1, 22% · R9_1] (21% ± 1pp), and the analogous rules flag R10/R11/R12_*/R22/R23. A consistent total set still validates; the hard rules are the totals and the control sum.
• Version-alignment trap. The attribute number does not encode the rate. In v12, R9=21%, R10=11%, R11=9%. An older instructions PDF describing R9=19% / R10=9% predates OPANAF 2131/2025 and must not be trusted — the XSD
• validator jar win.
• caen and cui are checked beyond the XSD pattern. caen is a closed enumeration (an arbitrary code fails; 6201 works — CAEN Rev.2 and Rev.3 both accepted); the jar additionally enforces the CUI check digit even though the XSD pattern is only [1-9]\d{1,9}.

v12 (current, retrieved 2026-07-17)

• XSD: https://static.anaf.ro/static/10/Anaf/Declaratii_R/AplicatiiDec/d300_v12_11022026.xml — note the .xml extension on a schema file. Namespace mfp:anaf:dgti:d300:declaratie:v12, root declaratie300.
• Shape: one empty element, everything is attributes (no children). 25 attributes are use="required"; the ~100 optional ones are the numeric rows R1_1…R65_2 (base/VAT column pairs) plus annex fields.
• Required set: luna, an, depusReprezentant (0/1), bifa_interne (0/1), temei (enum 0 or 2 only), nume_declar/prenume_declar/ functie_declar, cui, den, adresa, banca, cont, caen, tip_decont (enum L/T/S/A), pro_rata (0–100, 100 is the safe default), the four sector checkboxes bifa_cereale/bifa_mob/bifa_disp/ bifa_cons and solicit_ramb — Yes/No fields are D/N, not DA/NU — plus nr_evid and totalPlata_A.
• caen is a closed enumeration inside the XSD (carrying both CAEN Rev.2 and Rev.3 codes); an arbitrary code fails XSD validation, 6201 works.
• cui: XSD pattern is just [1-9]\d{1,9}, but the validator jar additionally enforces the CUI check digit (eroare atribut: cui: CUI invalid). Synthetic data needs a checksum-valid CUI (e.g. 1234565).
• nr_evid (23 digits) is checksum-verified by rule R25 ("cifra control eronata"). Compose it with anafpy's payment_evidence_number — never by hand.
• totalPlata_A is the control sum, not the amount payable: rule R26 requires it to equal the sum of every filled numeric row attribute (it is recomputed each time you add a field). An all-zero minimal return has totalPlata_A="0".
• Filling any detail row triggers a cascade of derived-row rules, reported incrementally (fix one, the next appears on rerun). For a single 21% sale (R9_1 base / R9_2 VAT — R9 is the 21% row in v12): R17_1/R17_2 totals (rules R65/R66) → R34_2 = max(R17_2 − R32_2, 0) (R110) → R37_2 (R113) → R41_2 = max(R37_2 − R40_2, 0) (R117). Missing values are reported as 'lipsa' with the expected value in parentheses — the messages effectively dictate the fix.
• VAT-rate coherence is a warning, not an error: rule R47 flags R9_2 outside 21% ± 1pp of R9_1 as atentionare (prefix A:); a wrong rate with consistent totals still validates. Totals and the control sum are the hard rules.
• Minimal valid instance (nil return, June 2026; nr_evid from payment_evidence_number(tip_decont="L", month=6, year=2026)):

<?xml version="1.0" encoding="UTF-8"?>
<declaratie300 xmlns="mfp:anaf:dgti:d300:declaratie:v12"
  luna="6" an="2026" depusReprezentant="0" bifa_interne="0" temei="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  banca="Banca Exemplu" cont="RO49AAAA1B31007593840000"
  caen="6201" tip_decont="L" pro_rata="100"
  bifa_cereale="N" bifa_mob="N" bifa_disp="N" bifa_cons="N" solicit_ramb="N"
  nr_evid="10301010626250726000042" totalPlata_A="0"/>

For a filled return, add e.g. R9_1="1000" R9_2="210" R17_1="1000" R17_2="210" R34_2="210" R37_2="210" R41_2="210" and set totalPlata_A="3050" (the sum of those seven values).

Older versions

The soft page keeps the full history; the previous rows are v11 (d300_v11_23092025.xml, Sep 2025 — the 21% VAT-rate revision window) and v10 (d300_v10_05062024.xsd). Pre-v11 schemas use the .xsd extension. The DUK jar validates only the current version — filing an old-schema instance is not a supported path.