Supported declarations

Source

Generated based on the official ANAF schema reference document `structura_D100-D710_0126_260326.pdf <https://static.anaf.ro/static/10/Anaf/Declaratii_R/AplicatiiDec/d100_24022022.xsd>`__.

Table of contents

Legal context

D100 is the monthly / quarterly / annual declaration through which Romanian taxpayers report their payment obligations to the state budget (Declarația privind obligațiile de plată la bugetul de stat).

Filing obligation: OPANAF 587/2016 as amended. Schema: OPANAF 0126/26.03.2026 (structura_D100-D710_0126_260326.pdf). XSD: `d100_24022022.xsd <https://static.anaf.ro/static/10/Anaf/Declaratii_R/AplicatiiDec/d100_24022022.xsd>`__.

Filing periodicity per obligation

The same XML element <declaratie100> is used for monthly (L), quarterly (T), semi-annual (S) and annual (A) obligations. The taxpayer files separate D100 declarations per period — but each declaration can include lines for multiple obligations of the same period.

Common scenarios:

Relationship with other declarations

D100 is part of a family of ANAF declarations that share the same l10n.ro.declaration infrastructure:

• D100 — payment obligations to state budget (this module).
• D101 — corporate income tax annual return (separate module, not yet implemented).
• D112 — payroll declaration (salary withholdings, separate flow).
• D300 — VAT (l10n_ro_declaration_D300).
• D390 — intra-community VAT recap (l10n_ro_declaration_D390).
• D394 — domestic operations recap (l10n_ro_declaration_D394).
• D406 — SAF-T (l10n_ro_declaration_D406).

If your company is a micro-enterprise that files D100 with code 121, it does not also file D101.

Data model

l10n.ro.anaf.declaration  ─┬── name = "d100"
                           │
l10n.ro.anaf.declaration.version
                           │   ─── name = "Versiunea 2"
                           │       date_from = 2022-02-24
                           │       model = l10n.ro.anaf.d100.v2
                           │
l10n.ro.anaf.d100.config  ─┘── nomenclator (107 records loaded as data)
                                cod_oblig, cod_bugetar, period_type,
                                account_code_from / account_code_to,
                                sign

l10n.ro.anaf.d100  (TransientModel — wizard base)
  └─ inherits l10n.ro.anaf.mixin
  └─ extended by l10n.ro.anaf.d100.v2 (XML generation logic per version)
       └─ generate_xmldict() → ordered fields
       └─ build_file() → assembled XML string
       └─ _compute_scadenta(cod_oblig) → due date
       └─ _compute_nr_evid(cod_oblig, scadenta_short) → unique record number
       └─ compute_from_config() → auto-fill obligation_line_ids from accounting

l10n.ro.anaf.d100.obligation  (TransientModel — line under wizard)
  ├─ cod_oblig
  ├─ cod_bugetar
  ├─ amount_due / amount_deductible / amount_to_pay / amount_to_refund
  └─ declaration_wizard_id (M2O parent)

Why account-range mapping is partial

The Romanian Chart of Accounts (PCG OMF 1802/2014) standardizes account names down to 4 digits (e.g. 4411 Impozit pe profit, 4418 Impozit microîntreprinderi, 4426 TVA deductibilă). Beyond that, analytical subdivision is at each company’s discretion.

For obligations with a clear standard PCG account (corporate income tax, microenterprise tax, dividend tax, disability fund), the module pre-maps a 6-digit range (e.g. 441100–441199). For industry-specific obligations (excise, gambling, mining, offshore wind, electricity producers, medicine clawback), the mapping is left empty intentionally — each taxpayer configures its own analytical accounts.

This avoids forcing a numbering convention on companies and keeps the standard mapping clean.

XSD schema reference

The output XML must validate against the official ANAF XSD: https://static.anaf.ro/static/10/Anaf/Declaratii_R/AplicatiiDec/d100_24022022.xsd

The schema defines:

• Required attributes on <declaratie100>: luna, an, cui, den, etc.
• Pattern constraints on nr_evid (23 digits with checksum).
• Allowed cod_oblig values (enumeration in the schema, must match nomenclator).
• Allowed cod_bugetar values per cod_oblig (often 5503 for state budget).
• Required scadenta format (DD.MM.YYYY).

ANAF updates the XSD periodically (hence the version system). When ANAF publishes a new version (e.g. d100_<DDMMYYYY>.xsd), a new sibling module should be added (e.g. l10n.ro.anaf.d100.v3) with the appropriate XML generation logic and date_from on the version record.

Prerequisites

Check the configuration steps from l10n_ro_declaration module downloaded with this module — ANAF declaration setup, signature configuration, company VAT/CUI fields and bank account.

Obligation codes nomenclator

This module ships with all ~107 D100 obligation codes loaded as configuration records in l10n.ro.anaf.d100.config. Each record describes:

Access the nomenclator from the menu: Accounting → Configuration → Romania → D100 — Obligation Configuration.

Account code mapping — what is configured by default

Out-of-the-box, the module maps only the obligations that use standard PCG RO chart-of-accounts subaccounts that any Romanian company will have:

Total: 12 obligations pre-mapped out of ~107.

Account code mapping — what you must configure manually

The remaining ~95 obligations are industry-specific and must be configured by each taxpayer individually, because:

1. The Romanian Chart of Accounts (OMF 1802/2014) does not standardize subaccounts below the 4-digit level for 446... (Alte impozite, taxe și vărsăminte asimilate). Each company defines its own analytical subdivision.
2. The taxes themselves are sector-specific and not all companies will encounter them (e.g. excise duties, gambling, mining royalties, offshore wind fees, electricity producer additional tax, medicine clawback).

If your company is liable for one of these, follow this procedure:

1. Create / identify the analytical account in your chart-of-accounts where you book the tax liability (typically a sub-account of 446 or 447). For example for excise duties on alcohol, you might use 4461.AA or 446100AA (depends on your numbering convention).
2. Open the D100 obligation record (Configuration → D100 — Obligation Configuration), find the corresponding cod_oblig (e.g. 211 — Excise beer).
3. Fill in Account Code From and Account Code To with the analytical account range (e.g. 446100–446199 if you use 6-digit codes).
4. Save. From now on, compute_from_config on the wizard will auto-pick balances from those accounts for that obligation.

If you don’t fill the account range, the obligation still works — you just need to enter the amounts manually in the wizard’s obligation lines table.

Industry quick-reference

D710 (declarație rectificativă)

D710 corrects a previously submitted D100. ANAF publishes a single combined nomenclator and identical XML structure for both — only the root element and namespace differ:

Because the structure is shared, this module ships a single wizard model that emits both forms. The dispatch happens in _DECL_FORMAT in models/v2/d100_20220224.py based on declaration_id.name. No separate obligation nomenclator is required — compute_from_config searches across all versions that target the same wizard model, so the D100 nomenclator automatically applies to D710 as well.

Open D710 from Accounting → Reporting → Romania → D710 Declaration.

Running the declaration

After configuration, generate the declaration as described in USAGE.md.

Steps

1. Open the wizard and complete the headers:
   • Declaration / Version — D100 / Versiunea 2 (default).
   • Date From / Date To — defaults to the current month / quarter; adjust if filing for a past period.
   • Signature — the digital signature record configured for your company.
   • Bank Account — the company bank account from which obligations are paid.
2. Compute obligations from accounting — click the „Compute from Accounting” button (icon 🧮). The wizard reads the D100 configuration nomenclator for the selected version and auto-fills the obligations table with amounts from the accounts mapped in account_code_from / account_code_to. The wizard re-opens automatically with the populated lines so you can review before generating.
3. Edit the obligations table if needed:
   • Add lines for industry-specific obligations not pre-mapped (excise, gambling, mining royalties, etc.) — see CONFIGURE.md.
   • Adjust any amount manually (Amount Due, Amount Deductible, Amount to Pay, Amount to Refund).
   • Remove lines you don’t need.
4. Optional fields for special situations:
   • Legal Basis (``temei``) — if filing under art.105 alin.(6) of Codul de Procedură Fiscală.
   • Successor (``succesor_id``) — if the declaration is filed by a successor entity (art.90 alin.4) — populates d_succ and cifS in the XML.
   • Corrected after Reserve Cancellation (``d_anulare``) — set Yes for the specific case in art.42 alin.4^1 Cod Fiscal.
   • Dissolution Without Liquidation (``d_dizolv``) — set Yes if filed at the point of dissolution.
5. Generate the XML — click „Get Report”. The wizard:
   • Produces an XML file according to the d100_24022022.xsd schema.
   • Validates against the XSD.
   • Saves the result on the file_save field with a download link.
6. Validate with DUKIntegrator — run ANAF’s local validator on the generated XML before signing.
7. Sign with the digital signature — use ANAF’s signing tool or your installed token (Sectigo, certSIGN, etc.).
8. Upload to ANAF at https://www.anaf.ro/anaf/internet/ANAF/servicii_online/inreg_inreg_pers_juridice under „Depunere declarații → D100”.

Key XML fields generated

The module generates a <declaratie100> (or <declaratie710> when filing a rectification) XML element with attributes:

• luna, an — period
• cui, den, adresa, telefon, mail — taxpayer identification
• nume_declar, prenume_declar, functie_declar — declarer info
• d_anulare, temei, d_succ, cifS, d_dizolv — optional flags
• totalPlata_A — total amount due (sum of all obligation amounts)

For each obligation line, an <obligatie> sub-element is added with:

• cod_oblig — obligation code
• cod_bugetar — ANAF budget code
• scadenta — payment deadline (format DD.MM.YYYY)
• nr_evid — unique 23-digit record number with checksum
• suma_dat / suma_ded / suma_plata / suma_rest — amounts (omitted if zero)

Quick reference: deadlines

December always rolls over to January of the next year.

Authors

• NextERP Romania

Contributors

• NextERP Romania:
  • Fekete Mihai <feketemihai@nexterp.ro>

Maintainers

Current maintainer:

This module is part of the NextERP-Romania/l10n-romania-enterprise project on GitHub.

You are welcome to contribute.