D710 — rectifying declaration (corrects D100-family filings)¶

The Declarație rectificativă (cod 14.13.01.00/r) that corrects payment obligations already declared on a D100. 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. D710 shares D100's entire wire structure, its obligation-code nomenclator and its structure annex; this guide documents only the delta — the two-column correction model — and cross-links d100.md and d100-nomenclatoare.md for everything they hold in common. ANAF's validator jar (D710Validator.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 D710Validator.jar J20.0.6.

Purpose & legal basis¶

D710 is the Declarație rectificativă — the instrument that corrects the state-budget payment obligations already declared on a D100. Per the instructions (anexa to OPANAF 587/2016, cod 14.13.01.00/r), it corrects the taxes and duties "declarate în formularul 100 … stabilite de către plătitori prin autoimpunere sau cu regim de reținere la sursă" — the same self-assessed and source-withheld obligations D100 carries. Each corrected line is one budget obligation picked from the same Nomenclatorul obligațiilor de plată la bugetul de stat that D100 uses (identified by the same 3-digit cod_oblig); D710's jar and D100's jar carry the identical code list (verified: the D710 version history adds 714–719, 701, 629, 115, 125, 494, 703 on the same dates as D100).

Current model: the D710 soft bundle, structure annex and DUK jar are published together with D100 and the current revision is approved by the same OPANAF 57/2026 (M.Of. 55/23.01.2026) amending the base order OPANAF 587/2016 (M.Of. 94/08.02.2016) that first approved the D100/D710 pair. The D710 instructions proper live in an annex to OPANAF 587/2016; the form code is 14.13.01.00/r.
What D710 does NOT correct. It is not a universal rectificative. Other declarations carry their own correction mechanism and must not be routed through D710:
D101 (profit tax) — re-file D101 with the correct figures and the "Declarație rectificativă" checkbox ticked (OPANAF 779/2024 added a second checkbox, "…ca urmare a unei notificări de conformare").
D300 (VAT decont) — has no rectificative form at all; errors are absorbed by the current decont's regularization rows or a tax-office material-error procedure (see d300.md).
D112 — payroll income tax and social contributions are corrected by a rectificative D112 (declarație rectificativă on the same format), never D710. This is the same D100 ↔ D112 boundary stated in d100.md: D710 corrects D100's obligations, not the salary-withheld ones.

Who files & when¶

Who: any taxpayer who has declared a D100 obligation and needs to change the declared amount for a past reporting period — because the original figure was wrong (self-assessment error, a withholding restated, an amount omitted or over-declared). One D710 covers one reporting period (luna + an, matching the D100 it corrects) and may carry many corrected obligation lines for that period.
Deadline: there is no fixed calendar deadline — a D710 is filed when the error is discovered, within the 5-year fiscal-prescription period ("termenul de prescripție de cinci ani", art. 110 Cod procedură fiscală, Legea 207/2015). Two independent sources agree: the D710 instructions set no submission term, and the CECCAR corrections note ties the window to the 5-year prescription. The one hard restriction the instructions state is that a correction may not be filed after annulment of the verification reserve, except when it flows from a fulfilled legal condition or a final court judgment — the d_anulare="1" / temei="2" header path.
Which value goes where (the semantics that define the form): the corrected column restates the full correct amount — not a delta — while the initial column holds the value previously declared. Per the instructions the initial column carries "suma completată în mod eronat în declarația 100" or "suma înregistrată anterior într-un alt formular 710", and the corrected column "suma corectă reprezentând impozitul sau taxa datorat". So a second correction of the same period sets the initial column to what the prior D710 declared, and the corrected column to the new correct total. ANAF re-computes the difference; the taxpayer states absolute values, never increments.

Filling guide¶

Shape: identical to D100 — a header element with repeating <obligatie> children, one child per corrected budget obligation. See the D100 filling guide for the header shape; the only structural difference is inside <obligatie>, where every amount attribute becomes a pair.

<declaratie710 luna an d_anulare … totalPlata_A …>
  <obligatie cod_oblig cod_bugetar scadenta nr_evid
             suma_dat_I suma_dat_C  suma_plata_I suma_plata_C … />  ← one per tax
</declaratie710>

The correction is two columns per amount. Where D100 has a single suma_dat, D710 has suma_dat_I (I = inițială, the value previously declared) and suma_dat_C (C = corectată, the full correct value). The five D100 amounts each split this way — the complete accepted set is suma_dat_{I,C}, suma_ded_{I,C}, suma_plata_{I,C}, suma_rest_{I,C}, suma_redu_{I,C} — capital _I/_C suffixes on the wire (the stale published XSD's lowercase _i/_c are rejected; the correct names come from the shared D100/D710 smart-PDF XML template). The completion model that ties the amounts together (suma_plata = suma_dat − suma_ded − …) is the same per-code model D100 enforces, applied to each column independently — see the D100 completion models.

Identification block (header attributes)¶

Identical to D100's — luna, an, d_anulare (0/1, required), optional temei (enum 2, only when d_anulare=1), d_succ/cifS, d_dizolv, nume_declar/prenume_declar/functie_declar, cui (jar-enforced check digit), den, adresa, optional telefon/fax/mai (note mai, not mail), and totalPlata_A. All of these were validated clean on D710 (the post-verification-reserve header d_anulare="1" temei="2" d_succ="0" d_dizolv="0" with contact fields passed). See the D100 identification block for the per-field notes — they carry over verbatim.

Obligation record (`<obligatie>`) → attributes¶

Attribute	Field	Notes
`cod_oblig`	Cod obligație	3-digit code from the shared nomenclator (annex); jar-enforced enum
`cod_bugetar`	Cod bugetar	budget account; jar-enforced per code (rule R14b) — same accounts as D100 (`604` → `5503` or legacy `20470101`)
`scadenta`	Scadența plății	dotted `d.m.yyyy`; the original obligation's due date for the corrected period
`nr_evid`	Nr. de evidență a plății	23 digits, checksum; same D100 layout (`cod_oblig` in the code slot)
`cota`	Cota impozit micro	micro (`121`) only; `1` for `an ≥ 2026`, null otherwise — mirrors D100
`suma_dat_I` / `suma_dat_C`	Suma datorată — inițială / corectată	previously declared / full correct value
`suma_ded_I` / `suma_ded_C`	Suma deductibilă — inițială / corectată	deductible leg pair
`suma_plata_I` / `suma_plata_C`	Suma de plată — inițială / corectată	amount-to-pay pair (per the code's completion model)
`suma_rest_I` / `suma_rest_C`	Suma de restituit — inițială / corectată	refundable pair
`suma_redu_I` / `suma_redu_C`	Reducere impozit — inițială / corectată	`121`/`130` only
`bifa_impozit_minim`	Bifă impozit minim	optional flag; accepted on D710 (`0`/`1`) — not on current D100

totalPlata_A (rule R11b) is the sum, over all obligation rows, of every filled amount attribute across both columns (suma_dat_I + suma_dat_C + suma_ded_I + suma_ded_C + suma_plata_I + suma_plata_C + suma_rest_I + suma_rest_C + suma_redu_I + suma_redu_C). It is a control sum, not the money owed. Verified: correcting suma_dat 80→100 and suma_plata 80→100 gives totalPlata_A = 80+100+80+100 = 360; the micro pair 1000→1100 on both legs gives 4200 (the jar names the expected value when it disagrees).

Common scenarios¶

Each instance below validated clean (ok) against D710Validator.jar J20.0.6 on 2026-07-17, for a June-2026 period. The synthetic cui="1234565" is check-digit valid; each nr_evid uses the D100 layout and passes rule R16.

1 — Correct a dividend withholding (Model 1#, cod 604): a June dividend tax was declared as 80 RON on the D100; the correct figure is 100 RON. The initial column restates 80, the corrected column 100:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie710 xmlns="mfp:anaf:dgti:d710:declaratie:v2"
  luna="6" an="2026" d_anulare="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="360">
  <obligatie cod_oblig="604" cod_bugetar="20470101" scadenta="25.07.2026"
    nr_evid="10604010626250726000048"
    suma_dat_I="80" suma_dat_C="100" suma_plata_I="80" suma_plata_C="100"/>
</declaratie710>

2 — Correct the Q2 micro-enterprise tax (Model 9#, cod 121): the micro tax for the second quarter was under-declared at 1 000 RON; the correct amount is 1 100 RON. cota="1" is mandatory (same rule as D100), and both the suma_dat and suma_plata legs carry the initial/corrected pair:

  <obligatie cod_oblig="121" cod_bugetar="5503" scadenta="25.07.2026"
    nr_evid="10121010626250726000042" cota="1"
    suma_dat_I="1000" suma_dat_C="1100" suma_plata_I="1000" suma_plata_C="1100"/>

with totalPlata_A="4200".

3 — Correction filed after annulment of the verification reserve: the narrow d_anulare="1" / temei="2" path (art. 105(6) lit. b, Legea 207/2015), with the optional contact fields. The obligation block is unchanged; only the header flags differ:

<?xml version="1.0" encoding="UTF-8"?>
<declaratie710 xmlns="mfp:anaf:dgti:d710:declaratie:v2"
  luna="6" an="2026" d_anulare="1" temei="2" d_succ="0" d_dizolv="0"
  nume_declar="Popescu" prenume_declar="Ion" functie_declar="Administrator"
  cui="1234565" den="EXEMPLU TEST SRL" adresa="Mun. Bucuresti, Str. Exemplu nr. 1"
  telefon="0211234567" fax="0211234568" mai="test@example.ro"
  totalPlata_A="360">
  <obligatie cod_oblig="604" cod_bugetar="20470101" scadenta="25.07.2026"
    nr_evid="10604010626250726000048"
    suma_dat_I="80" suma_dat_C="100" suma_plata_I="80" suma_plata_C="100"/>
</declaratie710>

Special attention & gotchas¶

The pitfalls below trace either to direct XSD/validator verification (the capital-suffix amount names, the D100↔D710 attribute delta, the totalPlata_A formula and the header flags were each observed against D710Validator.jar J20.0.6) or to an authoritative source (the D710 instructions in the OPANAF 587/2016 annex and the CECCAR corrections note for the scope, restate semantics and deadline). No uncorroborated practitioner claim is carried.

The amount attributes carry CAPITAL _I/_C suffixes on the wire. suma_dat_I/suma_dat_C, and likewise for ded/plata/rest/redu. The published XSD (d710_20012025.xsd) still declares v1 with lowercase suma_dat_i/_c — those are rejected as unknown attributes on the live v2 namespace. Author the capital form, recovered from the shared D100/D710 smart PDF's XML template. (See the version-alignment note below.)
Restate absolute values, never a delta. The corrected column is the full correct amount; the initial column is what was last declared — the original D100 figure, or the corrected figure from a prior D710 for the same period if this is a second correction. ANAF derives the difference itself. Putting the difference in the corrected column is the classic error.
D710 corrects D100 obligations only — it is not a universal rectificative. D101 is corrected by re-filing D101 (rectificativă checkbox); D300 has no rectificative form; D112 by a rectificative D112. Routing any of those through D710 is wrong. See Purpose & legal basis.
The D100↔D710 attribute delta is narrower than the combined annex suggests. The structure annex is a combined D100/D710 document and lists suma_spons, suma_AMEF, suma_bonif, Data_I, Data_IC, d_nInf, d_bonif, d_recN, anul_701/luna_701/ziua_701 and a "Zona 710" block. Direct verification against J20.0.6: every one of those is rejected on current D710 as "atribut necunoscut … in namespace='mfp:anaf:dgti:d710: declaratie:v2'" — they belong to historical D710 generations, not the live wire. The only obligation-level attribute D710 adds over D100 is the optional bifa_impozit_minim flag; the substantive delta is the split of each D100 amount into an _I/_C pair. (This corrects the D100 guide's note, which files bifa_impozit_minim/Data_I/d_nInf/etc. under "belong to D710" — only bifa_impozit_minim does; the rest are historical on both forms.)
totalPlata_A counts both columns. It is the sum of every filled amount attribute across both the initial and corrected legs of all rows — not just the corrected values, and not the net change. The jar (rule R11b) prints the value it computed when yours disagrees, so put a placeholder, run DUK once, and copy it.
The shared D100 rules all still apply per column. cod_bugetar is jar-enforced per code (rule R14b; 604 accepts 5503 or legacy 20470101), cota="1" is mandatory on micro (121) for an ≥ 2026, scadenta is the dotted d.m.yyyy original due date, nr_evid is the 23-digit D100 layout (cod_oblig in the code slot, checksum rule R16) — compose it with the same obligation_evidence_number(cod_oblig, month, year, due_date) D100 uses (MCP: declaratie_nr_evid with form="D710") — and the cui check digit is enforced. None of these differ from d100.md; the correction columns ride on top of them.

v2 (live wire format since periods ≥ 2014-11)¶

Namespace mfp:anaf:dgti:d710:declaratie:v2. The published XSD (d710_20012025.xsd, dated 2025!) still declares v1 — stale on two counts: wrong namespace for any period after Nov 2014, and wrong amount attribute names. The jar's internal router maps period → parameter generation (v1 wire until 2014-10, v2 after; ~30 parameter revisions inside).
Shape: like D100 — root declaratie710 header (luna, an, d_anulare, declarant, cui, den, adresa, totalPlata_A) + repeating obligatie.
The amount attributes carry CAPITAL suffixes on the wire: suma_dat_I/suma_dat_C, suma_plata_I/suma_plata_C (initial vs corrected; likewise suma_ded_*, suma_rest_*, suma_redu_*). The published XSD's lowercase suma_dat_i… are rejected as unknown attributes. (Recovered from the shared D100/D710 smart PDF's XML template.)
totalPlata_A control sum = sum of all amount attributes across both columns (rule R11b states the computed value, same family as D100).
cod_oblig/cod_bugetar pairing enforced as on D100 (604 ↔ 20470101 accepted with the same 8-digit code; the jar tells you the expected code when wrong). scadenta dotted d.m.yyyy; nr_evid same 23-digit layout as D100 (obligation code in the code slot).
The current Obligatie validator also accepts the optional bifa_impozit_minim flag (the minimum-tax flag). The historical attributes the combined annex lists — suma_spons, suma_AMEF, suma_bonif, Data_I, Data_IC, d_nInf, d_bonif, d_recN, anul_701/luna_701/ziua_701 — are rejected as unknown on the live v2 namespace (verified against J20.0.6); they belong to earlier D710 generations, not the current wire.
Minimal valid instance (June 2026, correcting dividend tax 80 → 100):

<?xml version="1.0" encoding="UTF-8"?>
<declaratie710 xmlns="mfp:anaf:dgti:d710:declaratie:v2"
  luna="6" an="2026" d_anulare="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="360">
  <obligatie cod_oblig="604" cod_bugetar="20470101" scadenta="25.07.2026"
    nr_evid="10604010626250726000048"
    suma_dat_I="80" suma_dat_C="100" suma_plata_I="80" suma_plata_C="100"/>
</declaratie710>