How to evaluate IFRS S2 reporting software

Search for IFRS S2 reporting software and you get two kinds of result. Paid ads from vendors, and ranked lists that read like they were assembled by someone who has never opened the standard.

Several of those lists recommend ERP and consolidation platforms. Those are useful products. They are not IFRS S2 disclosure tools, and the difference will cost you a cycle if you find out late.

This is not a ranking. It is the criteria I would apply, written by someone who sells one of the products in the category. That disclosure is at the end, and it says what our product does not do.

Why the search results for this query are wrong

The organic results for commercial IFRS S2 queries are dominated by affiliate roundups. They carry commission disclosures, they rank products they have not used, and several of them are visibly generated rather than researched.

The tell is the product list. If a page recommending IFRS S2 software lists general-purpose ERP suites and financial consolidation platforms alongside sustainability tools, the author has not understood the question. Those platforms were built for ledgers and group accounts. Handling a climate disclosure and the evidence behind it is not what they were designed for.

I am not going to name any product, ours included, in a ranking. What follows is what to test.

ERP and consolidation platforms are not IFRS S2 disclosure tools

Worth being fair about this, because the confusion is understandable.

An ERP or consolidation platform is excellent at moving and aggregating numbers across entities. If you run a group with forty subsidiaries, that capability is not optional and no disclosure tool replaces it.

What those platforms generally do not do is structure work against the disclosure requirements themselves, hold the link between a specific figure and the invoice behind it, or record review and approval at the level of an individual disclosure.

The practical answer for most groups is both. Consolidate where you already consolidate. Produce and support the disclosure somewhere built for it.

Criterion 1: paragraph coverage against the standard

Ask which parts of IFRS S2 the product actually structures work against.

A good answer names the disclosure requirements and shows you the structure. A weak answer is a blank rich-text field labelled "Governance" and a promise that you can put anything in it.

The difference shows up in month eight, when someone asks whether you have covered the governance body's oversight of targets, and nobody can tell without reading the standard again.

Criterion 2: evidence and audit trail

This is the one I would test first, because it is where most products are thinnest.

A file store attached to a project is not evidence. What matters is the link between a specific number and the specific document supporting it, retained after the person who uploaded it has left.

Test it concretely. Ask the vendor to show you a single figure and then produce the document behind it, the person who entered it, and any change since. If that takes more than a few clicks in a demo, it will not happen at all under deadline.

Criterion 3: sign-off and approval records

Most products have a status field. Fewer have an approval record.

The difference: a status says "approved". A record says who approved it, under what role, which version, at what time, and on what basis. The first is metadata. The second is evidence.

The question that separates them is whether an approval can be changed afterwards, and by whom. If an administrator can quietly edit an approval record, it is not a control. This is covered further in who signs off on a climate disclosure figure.

Criterion 4: multi-entity consolidation

If you report for a group, ask how the product handles the awkward cases rather than the clean one.

Two entities using different emission factors, legitimately, because their jurisdictions differ. Subsidiaries with different reporting calendars. An entity acquired in month seven. Intercompany energy sales that would otherwise be counted twice.

Every product demos well with one entity. The group case is where they diverge.

Criterion 5: an export your assurance provider can test

Ask to see the export you would hand an assurer. Then look at what is in it.

A PDF of the report is not it. What an assurance provider wants is the underlying material: the figures, the evidence files, the activity log, and something that lets them confirm the files have not changed since upload.

ISSA 5000 broadens tests of controls and encourages a controls-based approach. A product that cannot export in a testable form pushes your assurer toward substantive testing of individual numbers, which lands as more requests on your team.

Criterion 6: data provenance

For any figure, can the product tell you where it came from? Not the person — the origin. Which file, which sheet, which row.

This matters most for imported data, which is most data. A figure that arrived from a spreadsheet and kept no reference to it is a figure you cannot defend in eighteen months, as covered in could you reproduce this figure in eighteen months.

Criterion 7: exit and data portability

Ask what happens if you leave. In writing, before you sign.

What format do you get, does it include the evidence files and the activity log or only the figures, how long do you have, and what does it cost? A product that makes exit awkward is making a bet on your inertia.

This is also a governance question. If your evidence lives somewhere you cannot retrieve it from, your retention obligation is being met by a supplier relationship rather than by you.

The RFP questions to put in writing

Send these before the demo and ask for written answers. The pattern of what a vendor answers precisely and what they answer vaguely tells you more than the demo does.

The last question — what does the product not do — is the most useful one on the list. Every product has boundaries. A vendor who cannot name theirs either does not know their product or is not going to tell you.

The position, stated plainly: evaluate on evidence handling, not on features. Feature lists converge because vendors copy each other. What does not converge is whether the record behind a figure survives contact with an assurance provider eighteen months later. Test that, on your own data, before you sign anything.

Common questions

Can we use our ERP or consolidation platform for IFRS S2?

You can hold the numbers there. What those platforms are generally not built for is structuring work against the disclosure requirements, linking a source document to a specific figure, and recording review and approval at disclosure level. Many groups end up using both: the ERP for financial consolidation, and something purpose-built for the disclosure and its evidence.

What should we ask an IFRS S2 software vendor?

Seven things in writing: whether a recorded approval can be edited or deleted afterwards and by whom, what the assurance export actually contains, what provenance is retained for a single figure, how the product handles different emission factors across entities, what you get on exit and at what cost, which IFRS S2 paragraphs the product structures work against, and what the product does not do.

Is there a ranking of the best IFRS S2 reporting software?

Not one worth trusting. The rankings that appear in search results are largely affiliate content, and several of them list ERP and consolidation platforms that are not IFRS S2 disclosure tools at all. We sell a product in this category, which is exactly why we publish evaluation criteria rather than a ranking.

What matters most when evaluating this software?

Whether the evidence behind a figure survives. Most products can capture a number. Far fewer retain the source document, the recorded approval and the change history in a form an assurance provider can test. If you only have time to test one dimension, test that one.