IT Glossary
What is XML?
The veteran structured data format: tags that describe the content — the official language of Romanian electronic invoicing and enterprise exchange.
Rigour is what XML was built for, and rigour is why it refuses to retire. The eXtensible Markup Language wraps information inside tags that describe it, producing documents both machines and people can read, and its defining virtue is that schemas define exactly which fields exist, in what order and of what type, so a document can be validated automatically against the standard it claims to follow. That is precisely what you want when an invoice or a tax return has to comply to the comma. Hence its place in Romanian business life, more relevant now than ever. E-Factura, Romania’s mandatory business-to-business e-invoicing system, speaks it: the file carrying fiscal value, transmitted through SPV, the online taxpayer portal of ANAF, the Romanian tax authority, is an XML document in an international invoicing standard, and the PDF is merely its courtesy shadow. SAF-T reporting — the standard audit file for tax, filed periodically from accounting data — works the same way, as do a long list of returns, bank statement exchange formats, product catalogues shared between partners, older enterprise interfaces and configuration files. Its younger relative JSON won the modern web through simplicity, but strict validation against an official standard keeps this format king wherever tax, banking and institutions are involved.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247
Why it matters for your business
The official language of digital tax compliance
Electronic invoicing, standardised audit reporting and returns live as documents validated against official schemas, so systems that speak it correctly pass while the rest collect rejections.
Strict validation, precise errors
A document checked automatically against a schema fails with an exact message, so a missing field is repaired at the point of failure rather than guessed at over the phone.
An archive readable for decades
Structured plain text stays accessible with any tool at any time, which is what you want from the format holding a company’s fiscal history long after the software has gone.
Frequently asked questions
Why does electronic invoicing use XML rather than an ordinary PDF?
Because the purposes differ. A PDF is made for eyes: it looks the same everywhere, but extracting data from it is automated guesswork. This format is made for systems, with every piece of information in a field the standard defines, automatically validatable and importable into the recipient’s accounting without errors. An invoice as data rather than as a picture is exactly what allows the whole chain to be automated, from validation at the authority to automatic booking at the receiving company. The PDF stays legitimate as a visual courtesy generated from the data.
The tax authority keeps rejecting our invoice files — what does that mean and who fixes it?
A rejection is a validation verdict: the generated document does not respect the schema. Typical cases are missing or wrong codes for units of measure, VAT rates or countries, empty mandatory fields, broken structures and incorrect identification data. The error message points precisely at the problem even when the language is technical, and the repair belongs to the software that generated the file, so your supplier corrects the mapping while you report the complete error. Repeated rejections of the same type signal software not updated to the current schema version.
A large partner wants our data in their own schema — is that a big project?
Usually not. It is a standard transformation integration: your data from the ERP or stock system is mapped onto the structure their schema requires and exported automatically, on a schedule or on an event. The tools and the practice have existed for decades, and typical effort is measured in days rather than months — provided three things are clarified at the start: the exact schema with valid examples from the partner, the transport rules covering where and how files are sent, and how validation errors get handled.
Let’s talk about your project
Message us on WhatsApp or send an email — you talk directly to a developer.
office@northdan.com · +40 752 070 247