D205 — annual informative on income tax withheld at source (per beneficiary)¶

Per-beneficiary yearly informative filed by income payers. 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 (D205Validator.jar) and the structure annex are the authority; this guide is a distilled bridge, not a re-implementation of the rules. The two "Common scenarios" instances were proven hands-on on 2026-07-17 against D205Validator.jar J9.0.5 / D205Pdf.jar P5.0.1 (feed directory D205_36): a one-beneficiary dividends sample and a two-income-type / three-beneficiary sample both validated clean and rendered to PDF.

Purpose & legal basis¶

The declarație informativă privind impozitul reținut la sursă și câștigurile/pierderile din investiții, pe beneficiari de venit is the payer's annual, per-beneficiary report of tax it withheld at source during a year. It does not settle a payment (the tax was already withheld and paid monthly via D100) — it is informative, breaking the year's withholdings down by beneficiary (CNP/NIF) and by income type so ANAF can correlate what each individual owes against what the payer reported. It is filed under art. 132 alin. (2) of the Fiscal Code (Legea 227/2015).

Current model: approved by OPANAF 102/2025 (M.Of. 65/27.01.2025), per the order chain the structure annex carries (Conform OPANAF nr. 102/2025, superseding 154/2024, 18/2023, 48/2019). The wire schema was structurally refreshed on 12.02.2026 — the change that added income type 30 (transfer of dismemberments of the property right under suspensive condition) and the dividend-rate step to 16% for 2026. The published form facsimile still bears an older Anexa nr. 1 la Ordinul nr. 179/2022 caption (a carried-forward template header) — read the current field set from the XSD + structure annex, not from the facsimile's order caption.
Periodicity: annual. The reporting period is fixed — the XSD pins luna="12" and enforces an ≥ 2025; an is the reporting year (the year whose income is reported), not the filing year.

Who files & when¶

Who: plătitorii de venituri — every income payer that calculates, withholds, and pays tax at source on behalf of a beneficiary (art. 132 alin. (2) Fiscal Code). One D205 per payer per year, aggregating all withheld income types and all beneficiaries. Salary and salary-assimilated income is NOT reported here — it rides the monthly D112; D205 covers the non-salary withheld categories (dividends, interest, prizes, gambling, other sources, rent paid by legal persons, and the investment-transfer gains/losses).
Deadline: the last day of February (inclusive) of the year following the reporting year — income of year N is reported by end-February of year N+1 (art. 132 alin. (2) Fiscal Code). When that day falls on a weekend the deadline rolls to the next working day: for the FY2025 return this is 2 March 2026.
Corrections (d_rec): a rectificative D205 (d_rec="1") carries only the rows that correct the initial filing, not the whole population. To delete a previously reported category for a beneficiary, file a rectificative with that category's value fields zeroed (structure annex, field d_rec). There is no separate deletion document.
Succession (d_succ): d_succ="1" marks a return filed for a ceased taxpayer under art. 90 alin. (4) of the Fiscal Procedure Code (Legea 207/2015); it is the only case in which cifSS (successor's fiscal code) is present — see the gotchas.

Filling guide¶

The document is one <declaratie205> element carrying the payer identification block as attributes, plus two kinds of child rows: sect_II (Section II — the per-income-type recapitulative totals, 1..n) and benef (Sections III/IV/V/VI — one row per beneficiary-per-income-type, 1..n). Every benef row of a given tip_venit1 must be summarised by exactly one matching sect_II of the same tip_venit, and the totals must reconcile.

Identification block (root attributes)¶

Attribute	Form field	Notes
`luna`	Perioada de raportare — luna	fixed `12` (annual)
`an`	Anul	reporting year; XSD enforces ≥ 2025
`d_rec`	Declarație rectificativă	`0` initial / `1` rectificative
`d_succ`	Declarație depusă potrivit art. 90 alin. (4) L207/2015	`0`/`1` (succession)
`cifSS`	Cod de identificare fiscală a succesorului	XSD-required but must be absent unless `d_succ="1"` — jar wins
`nume_declar` / `prenume_declar` / `functie_declar`	Nume / Prenume / Funcție declarant	required text
`cui`	Cod de identificare fiscală (plătitor de venit)	CUI check-digit enforced by the jar
`den`	Denumire / Nume și Prenume	required
`adresa`	Adresă domiciliu fiscal	required
`telefon` / `fax` / `mail`	contact	optional
`totalPlata_A`	Suma de control	control sum, not an amount payable — see gotchas

Section II — recapitulative totals (`sect_II`, one per income type)¶

All eight attributes are use="required" (present, 0 when not applicable). Each must equal the sum of the matching field across the benef rows of that tip_venit.

Attribute	Form column	Reconciliation rule
`tip_venit`	Tip de venit	income-type code (nomenclature below)
`nrben`	Număr beneficiari de venit	`= count(benef)` of this `tip_venit`
`Tcastig`	Total câștig	`= Σ castig1`, only `tip_venit=25`; else `0`
`Tpierd`	Total pierdere	`= Σ pierdere1`, only `tip_venit=25`; else `0`
`T_VB`	Total venit brut plătit exclusiv în natură	`= Σ VB`, only `tip_venit=29`; else `0`
`T_GAR`	Total sumă garanție chirie	`= Σ GAR`, only `tip_venit=29`; else `0`
`Tbaza`	Total bază de calcul a impozitului	`= Σ baza1` for `tip_venit ≠ 25`
`Timp`	Total impozit reținut	`= Σ imp1` for `tip_venit ≠ 25`

Sections III–VI — per-beneficiary rows (`benef`)¶

Attribute	Form field	Rule
`id_inreg`	ID înregistrare	unique per row
`tip_venit1`	III. Tip venit	income-type code; keys the row to its `sect_II`
`den1`	1. Nume și prenume / Denumire	required
`Rezid`	2. Rezident / Nerezident	`1` resident / `2` non-resident (constraints below)
`Stat_R`	3. Statul de rezidență	2-char country code, required iff `Rezid=2`, else absent
`cifR`	4. CNP / NIF din România	CNP/NIF, check-digit enforced
`cifS`	5. CIF din străinătate	must be absent if `Rezid=1`
`tip_plata`	6. Regim fiscal	`0`/`2`/`3` — must correspond to `tip_venit1` (table below)
`castig1` / `pierdere1`	7./8. IV. Câștig / Pierdere	only `tip_venit1=25`; `≥ 0`
`divid_D` / `divid_P`	3./4. V. Dividende distribuite / plătite	only `tip_venit1=08`; `≥ 0`
`VB` / `GAR`	VI. Venit brut în natură / Sumă garanție	only `tip_venit1=29`; `≥ 0`
`baza1`	9. Baza de calcul a impozitului	for `tip_venit1 ≠ 25`; `≥ 0`
`imp1`	10. Impozit reținut	for `tip_venit1 ≠ 25`; `≥ 0`

Uniqueness (structure annex, "Validări suplimentare"): the key is (cifR + id_inreg) for tip_venit1=25 and (tip_venit1 + cifR) for tip_venit1 ≠ 25 — i.e. a beneficiary may appear once per income type (and, for investment-gold gains 25, once per registration id).

Rezid constraints (structure annex, field 2): Rezid is forced to 1 (resident) for tip_venit1 ∈ {08, 09, 11, 12}; it may be 1 or 2 for {04, 16, 18, 25, 26, 27, 28, 29, 30}.

Income-type nomenclature (`tip_venit` / `tip_venit1`)¶

The XSD enum lists 01–30, but the jar accepts only the current set ("valoarea '01' nu se afla in lista"): 04, 08, 09, 11, 12, 16, 18, 25, 26, 27, 28, 29, 30. Rates track the reporting year; read the exact rate from the structure annex's nomenclator, not from the code.

Code	Income type	Rate	`tip_plata`	Extra fields
`04`	Activități independente (art. 68² CF) + alte surse (art. 114 (2) k¹)	10%	`2`	`baza1`,`imp1`
`08`	Dividende (Section V)	8%/2024, 10%/2025, 16%/2026	`2`	`baza1`,`imp1`,`divid_D`,`divid_P`
`09`	Dobânzi (interest)	10%	`2`	`baza1`,`imp1`
`11`	Lichidarea persoanei juridice	10%	`2`	`baza1`,`imp1`
`12`	Premii (prizes)	10%	`2`	`baza1`,`imp1`
`16`	Alte surse (altele decât art. 114 (2) k¹)	10%	`2`	`baza1`,`imp1`
`18`	Jocuri de noroc (impozit pe tranșe)	tranșe	`2`	`baza1`,`imp1`
`25`	Câștiguri/pierderi din transferul aurului de investiții (Section IV)	—	`0`	`castig1`,`pierdere1`
`26`	Câștiguri din transferul titlurilor deținute ≥ 365 zile	1%	`2` or `3`	`baza1`,`imp1`
`27`	Câștiguri din transferul titlurilor deținute < 365 zile	3%	`2` or `3`	`baza1`,`imp1`
`28`	Bacșiș încasat de salariați	10%	`2`	`baza1`,`imp1`
`29`	Cedarea folosinței bunurilor (rent) plătit de PJ (Section VI)	10%	`2`	`baza1`,`imp1`,`VB`,`GAR`
`30`	Transferul dezmembrămintelor dreptului de proprietate sub condiție suspensivă	—	`2`	`baza1`,`imp1`

tip_plata (6. Regim fiscal): 0 = not completed, 2 = impozit final, 3 = neimpozabil potrivit convenției (double-tax treaty). It must match tip_venit1 (rule R37): 0 only for 25; 2 for the withheld types; 2 or 3 only for 26/27 (a non-resident under a treaty).

Retired codes still in the XSD. The schema keeps 01, 02, 03, 05, 06, 07, 10, 13, 14, 15, 17, 19, 21, 22, 23, 24, but the jar rejects them. Notably 01 (drepturi de proprietate intelectuală), 15 (arendă), and 07 (salarii) are no longer D205 categories — intellectual-property and rent-of-agricultural land income are now self-assessed by the beneficiary (Declarația unică / D212), and salaries go through D112. Do not author these codes.

Common scenarios¶

Each instance below validated clean (ok) against D205Validator.jar J9.0.5 on 2026-07-17 (the dividends one also rendered a PDF via D205Pdf.jar P5.0.1). The payer cui="1234565" is check-digit valid; the beneficiary CNPs are synthetic but checksum-valid. totalPlata_A is the control sum from the sect_II totals only (rule R15 states the expected value on mismatch — author 0, read the error, set it).

1 — Minimal dividends return (one resident beneficiary, 1 000 lei dividends distributed and paid, 100 lei tax withheld at the 2025 rate of 10%; FY2025). totalPlata_A = nrben(1) + Tbaza(1000) + Timp(100) = 1101:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie205 xmlns="mfp:anaf:dgti:d205:declaratie:v3"
  luna="12" an="2025" d_rec="0" d_succ="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  totalPlata_A="1101">
  <sect_II tip_venit="08" nrben="1" Tcastig="0" Tpierd="0" Tbaza="1000"
    Timp="100" T_VB="0" T_GAR="0"/>
  <benef id_inreg="1" tip_venit1="08" den1="Ionescu Maria" cifR="1850615410019"
    tip_plata="2" Rezid="1" baza1="1000" imp1="100" divid_D="1000" divid_P="1000"/>
</declaratie205>

2 — Two income types, three beneficiaries: dividends (08) for two beneficiaries plus one prize (12 premii). Note the two sect_II blocks, each reconciling its own benef rows, and that dividends carry divid_D/divid_P while premii carry only baza1/imp1. totalPlata_A = nrben(2+1) + Tbaza(5000+500) + Timp(500+50) = 6053:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie205 xmlns="mfp:anaf:dgti:d205:declaratie:v3"
  luna="12" an="2025" d_rec="0" d_succ="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  totalPlata_A="6053">
  <sect_II tip_venit="08" nrben="2" Tcastig="0" Tpierd="0" Tbaza="5000"
    Timp="500" T_VB="0" T_GAR="0"/>
  <sect_II tip_venit="12" nrben="1" Tcastig="0" Tpierd="0" Tbaza="500"
    Timp="50" T_VB="0" T_GAR="0"/>
  <benef id_inreg="1" tip_venit1="08" den1="Ionescu Maria" cifR="1850615410019"
    tip_plata="2" Rezid="1" baza1="2000" imp1="200" divid_D="2000" divid_P="2000"/>
  <benef id_inreg="2" tip_venit1="08" den1="Georgescu Ana" cifR="2850512420024"
    tip_plata="2" Rezid="1" baza1="3000" imp1="300" divid_D="3000" divid_P="3000"/>
  <benef id_inreg="3" tip_venit1="12" den1="Vasilescu Radu" cifR="2920701410052"
    tip_plata="2" Rezid="1" baza1="500" imp1="50"/>
</declaratie205>

Special attention & gotchas¶

The pitfalls below trace either to direct XSD/validator verification (the control sum, the totals reconciliation, the cifSS/d_succ contradiction, the narrowed tip_venit set, and the tip_plata/Rezid correspondences were each observed against D205Validator.jar J9.0.5) or to an authoritative source (OPANAF 102/2025's form facsimile, the structure annex, and art. 132 Fiscal Code for the deadline and filer). No uncorroborated practitioner claim is carried.

Code ≠ label: 08 is dividends, 12 is premii. The form's Section V is titled "IMPOZITUL PE VENITURILE DIN DIVIDENDE" and carries divid_D/divid_P under tip_venit=08; 12 is venituri din premii (prizes) with only baza1/imp1. A dividends row that omits divid_D/divid_P, or a code 12 row that carries them, is wrong even if the arithmetic ties.
cifSS is XSD-required but the jar forbids it unless d_succ="1". Rule R4b ("cifSS … # null daca d_succ = 1") means the successor fiscal code is present iff the succession flag is set. The XSD's use="required" and the jar contradict each other — the jar wins; omit cifSS on an ordinary return.
tip_venit is narrower than the XSD enum. The schema still lists 01–30, but the current parameter set is 04, 08, 09, 11, 12, 16, 18, 25, 26, 27, 28, 29, 30. Retired codes — including 01 (drepturi de proprietate intelectuală), 15 (arendă), 07 (salarii) — fail with "valoarea '…' nu se afla in lista"; those income streams are reported elsewhere (D212 / D112), not on D205.
The sect_II totals must reconcile with the benef rows exactly. nrben is a count, Tbaza/Timp are sums over every non-25 type, while Tcastig/Tpierd sum only the 25 rows and T_VB/T_GAR only the 29 rows. All eight are required and default to 0, so a missing total reads as a zero that then fails the sum.
totalPlata_A is a control sum, not an amount to pay. Rule R15 requires totalPlata_A = Σnrben + ΣTcastig + ΣTpierd + ΣT_VB + ΣT_GAR + ΣTbaza + ΣTimp across all sect_II blocks. It is built from the recapitulative totals, so the per-beneficiary divid_D/divid_P/VB/GAR fields do not enter it (in scenario 1, 1000 + 100 + 1 = 1101). D205 settles no payment — the tax was withheld and paid during the year.
tip_plata and Rezid are constrained by the income type. tip_plata="0" is valid only for investment-gold gains (25); "3" (treaty-exempt) only for 26/27. Rezid is forced resident (1) for 08/09/11/12; a non-resident (Rezid="2") requires Stat_R from the country nomenclature and a foreign cifS, and a resident must not carry cifS.
Dividend rate follows the year, and distributed ≠ paid. For 08 the rate steps 8% (2024) → 10% (2025) → 16% (2026); divid_D (distributed) and divid_P (actually paid) are separate ≥ 0 fields — a year can distribute more than it pays. Set imp1 from the year's rate on baza1, not from a fixed percentage.
Deletion and correction go through d_rec, not a separate document. A rectificative (d_rec="1") carries only the corrected beneficiary rows; deleting a previously reported category means filing that category's value fields as zero. The initial return is otherwise not re-sent.
Cross-declaration reconciliation is the real filing risk. D205's whole purpose is correlation: the withheld amounts it reports per beneficiary feed that beneficiary's own annual D212 (Declarația unică — notably the CASS threshold on dividend income), and they must tie to what the payer declared and paid monthly via D100 (budget position 604 = dividends withheld from natural persons is the confirmed mapping; the other withholding positions map analogously, but the specific D100 codes for the non-dividend types were not corroborated in this pass and are left unstated). A D205 that disagrees with the matched D100 line is the mismatch ANAF surfaces.

v3 (current wire; XSD `d205_2025_v3.xsd`, jar J9.0.5)¶

Namespace mismatch inside the published XSD: the file is named …_v3.xsd but its targetNamespace still reads mfp:anaf:dgti:d205:declaratie:v2. The validator demands v3 — use the filename's version (mfp:anaf:dgti:d205:declaratie:v3), not the file's.
Shape: root declaratie205 (annual — luna="12", an = reporting year ≥ 2025) + per-income-type totals sect_II (1..n) + per-beneficiary benef rows (1..n).
cifSS (successor CIF) is use="required" in the XSD but must be ABSENT unless d_succ="1" — jar rule R4b: "cifSS … # null daca d_succ(0) = 1". The XSD and the jar contradict each other; the jar wins.
tip_venit is narrower than the XSD's 01–30 enum: the current parameter set accepts only 04, 08, 09, 11, 12, 16, 18, 25, 26, 27, 28, 29, 30 ("valoarea '01' nu se afla in lista") — the retired income types are gone even though the schema still lists them. 08 = dividends (needs divid_D/divid_P); 12 = premii (prizes).
tip_plata must correspond to tip_venit (rule R37): 2 (impozit final) for dividends 08 and the other withheld types, 0 only for investment-gold gains 25, 3 only for treaty-exempt 26/27.
Totals rows must agree: sect_II per type carries nrben, Tbaza, Timp (+ capital-gain fields Tcastig/Tpierd, and T_VB/T_GAR), matching the benef rows of that type.
totalPlata_A control sum counts bases + taxes + beneficiary counts (scenario 1: 1000 + 100 + 1 = 1101; rule R15 states the expected value — author 0, read, set).
Minimal valid instance (one resident beneficiary, 1000 RON dividends distributed and paid, 100 RON tax withheld at the 2025 rate, FY2025):

<?xml version="1.0" encoding="UTF-8"?>
<declaratie205 xmlns="mfp:anaf:dgti:d205:declaratie:v3"
  luna="12" an="2025" d_rec="0" d_succ="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  totalPlata_A="1101">
  <sect_II tip_venit="08" nrben="1" Tcastig="0" Tpierd="0" Tbaza="1000"
    Timp="100" T_VB="0" T_GAR="0"/>
  <benef id_inreg="1" tip_venit1="08" den1="Ionescu Maria" cifR="1850615410019"
    tip_plata="2" Rezid="1" baza1="1000" imp1="100" divid_D="1000" divid_P="1000"/>
</declaratie205>