Conversion tool vs platform the trade-off
iXBRL conversion delivers a valid file for one deadline — and that is exactly what it promises. Taxxor Disclosure Manager is built for a different question: how does the entire report — figures, text, tagging and design — come out consistent from one source, year after year? Here is the trade-off, including what a platform asks in year one.
A conversion tool does what it promises. The question is what it promises.
With one format, one mandate and figures that are final early, conversion is workable. The arithmetic changes once reporting is an annual process with multiple formats and an auditor who wants to trace figures — and that is exactly the process a platform is built for.
| Conversion tool | Platform | |
|---|---|---|
| What it solves | This year’s filing | The reporting process, every year |
| Starting point | A finished document (PDF or Word) | Structured data from source systems (SAP S/4HANA, SAP BW, LucaNet, Excel) |
| Next financial year | Convert again; tag reuse breaks when the structure changes | Mapped once, then rolled forward to every next report |
| A figure changes just before the deadline | Document back, re-convert, re-check everything | The change propagates to PDF, iXBRL and web version under control |
| Regenerating the filing | Another round with the provider, within their turnaround | Regenerate at any moment, no waiting time; every rendering is stored with its audit trail |
| Consistency across formats | Check the whole converted document against the report, also outside the tagged scope | Every format comes from the same source and cannot drift apart |
| Control and audit | Tags after the fact, no traceability to the source | Full data lineage, change tracking and an audit trail |
| Who decides the tagging | Concept choices and extension elements with the provider, accountability with the filing organisation | The mapping sits with the organisation itself and can be adjusted at any moment |
| New or stricter rules | More tagging work per tightening — or an extra tool per new mandate | Load the new taxonomy and report — same software |
| Output formats | The compliance file | Print-ready PDF, PDF for online, web, MS Word, MS Excel and iXBRL/XBRL — from the same source |
Viewed per year, conversion looks manageable and a platform looks like an investment. Over three reporting cycles that picture flips, provided the work of year one is counted in.
Moving to a platform is real work in year one. Source data is mapped to the reporting requirements, the brand style is ported to the report design package, taxonomies are loaded and the existing report is rebuilt in the new structure. That is more than having a file converted — and it is exactly the work that never comes back: from then on, the mapping, the brand style and the report structure are the starting point of every next report.
The report rolls forward: update figures and text, load the annual taxonomy update, report. The work sits where it belongs — in the content of the report — no longer in rebuilding formats and tagging. When a mandate gets more granular, the existing mapping grows with it.
The same routine every year: finish the report, have it converted, reconcile, re-check. That check covers the whole converted document and not only the tagged parts, and every new round runs on the provider’s turnaround. The annual costs add up without building anything, and the risk stays the same size every year: diverging versions, late changes that don’t carry through, a filing nobody can trace.
So the real comparison is not “cheap file versus expensive software”, but: three years of recurring conversion work that builds nothing, against setting up once and rolling forward.
The structural difference sits under the hood. Taxxor DM is not built for one mandate — it is built to read any taxonomy: SBR, ESEF, SEC, CSRD/ESRS and whatever comes next. A new mandate or the annual taxonomy update therefore means: load the new taxonomy and map the source to it. No new software, no new project.
That is also why more granular requirements within existing rules don’t hit the platform the way they hit a conversion routine. When block tagging becomes detailed tagging, a conversion routine faces more after-the-fact tagging on a finished document, every year. For the platform it is the same move as always: extend the existing mapping one level deeper — self-service, including own extension elements where the mandate allows them, which keeps the choice of which figure maps to which concept inside the organisation rather than with an outside provider.
The architecture is what makes that possible: data-first, not document-first. Because figures, text and tags flow through one system, more granular tagging is a matter of mapping the source in more detail — not of a bigger conversion project. Rules that tighten make a conversion routine steadily more expensive; a platform with a taxonomy-agnostic engine absorbs them.