ESG reporting is usually treated as an annual project — hire help, produce a report, repeat. As we've argued elsewhere, given how often the underlying requirements are shifting, a more durable approach is to treat it as infrastructure: a system that keeps working as the rules change around it. That's easy to state as a principle and much harder to picture concretely. What does it actually mean, in practice, for a system to "stay current on which rules apply" or be "re-run against a new jurisdiction without starting over"?
This piece is an attempt to make that concrete — four layers of what that infrastructure looks like, with a worked example running through each.
The four layers
Think of the system as four distinct layers, each solving a different problem. Most organizations that struggle with reporting have accidentally collapsed all four into one overworked spreadsheet, maintained by one overworked person. Separating them is most of the fix.
Layer 1: Continuous data ingestion, not annual data collection
The traditional model is a once-a-year scramble: someone emails every supplier in Q4 asking for last year's emissions data, chases non-responders, and manually keys whatever comes back into a master spreadsheet, one row at a time.
The infrastructure version treats this as an ongoing pipeline, not a campaign. Supplier invoices, utility bills, logistics records, and procurement data already flow through your systems continuously — the reporting problem is mostly that this data is unstructured, arrives in inconsistent formats, and isn't tagged to emissions categories as it comes in.
Practical example: A mid-sized manufacturer receives freight invoices from a dozen logistics providers, each in a different PDF layout, listing shipment weight and distance but not emissions. Instead of a person manually converting this once a year, an AI-based extraction layer processes each invoice as it arrives, pulls the relevant fields, applies the appropriate emissions factor (fuel type, freight mode, distance), and writes a structured record into a running dataset. By the time reporting season arrives, twelve months of Scope 3 transport data already exists in usable form — nobody re-keyed a single row in Q4.
The output of this layer isn't a report. It's a clean, continuously updated dataset that any report — this year's or a future one — can be built from.
Layer 2: A regulatory change–monitoring layer, separate from your reporting logic
This is the layer most organizations don't have at all. When a threshold changes — Singapore delaying ISSB timelines by market cap tier, the EU cutting mandatory datapoints by 61%, California setting a firm August 2026 deadline for SB 253 — someone has to notice, understand what changed, and figure out what it means for your specific obligations. Right now, that "someone" is usually a person reading trade newsletters and hoping they don't miss anything.
Practical example: Instead of relying on one person to track SGX circulars, EU Omnibus amendments, and US state-level rules simultaneously, this layer continuously monitors regulatory sources and maintains a structured, current answer to a narrower question: given our company's size, listing status, and the jurisdictions we operate in, what exactly are we obligated to report, and by when? When SGX RegCo pushed non-STI companies under S$1 billion market cap to FY2030, this layer's job is to flag, within days, that your specific reporting deadline just moved — rather than your team discovering it by chance three months before a filing you thought was due.
Critically, this layer is separate from your actual reporting logic. It answers "what applies to us and when," not "how do we produce the report." That separation is what lets requirements change without your whole process breaking — you're updating one input, not rebuilding the system.
Layer 3: A framework-mapping layer that decouples your data from any single standard
This is the layer that actually delivers on "re-run without starting over." Most reporting failures happen because a company built its process around one specific framework's structure — its categories, its terminology, its exact data points — so when a second jurisdiction's requirements arrive, or the framework itself changes, the whole process needs to be redone from scratch.
The alternative is maintaining your underlying data in a framework-agnostic structure — raw activity data (fuel consumed, electricity purchased, freight distances, supplier-reported figures) tagged with enough metadata to be mapped into any framework's categories, rather than pre-formatted for one.
Practical example: A Singapore-headquartered company listed on SGX and also selling into the EU needs to satisfy both IFRS S2 (Scope 1/2/3, STI-tier timelines) and CSRD-adjacent supply-chain requests from EU customers, which use a different category structure (the ESRS's 15 Scope 3 categories). If the underlying dataset is built to IFRS S2's format specifically, meeting the EU request means re-collecting and re-categorizing data that already exists — essentially redoing the work. If instead the raw data is stored generically (this shipment, this fuel type, this distance, this date) with a mapping layer that translates it into whichever framework's categories are needed on output, both reports draw from the same underlying dataset. Add a third jurisdiction next year, and it's a new mapping definition, not a new data collection exercise.
Layer 4: An assurance-ready draft layer, with a human checkpoint built in
The final layer takes the outputs of the first three — clean data, current requirements, framework-mapped structure — and produces an actual draft disclosure: narrative sections on governance and strategy, populated tables, flagged gaps where data is missing or thin.
This is also where the human checkpoint belongs, deliberately. Anything headed for external assurance — the gross emissions figures that regulators are increasingly requiring to be reported without netting against carbon credits — should be treated as a draft requiring sign-off, not a finished answer. The AI's job here is to compress the time from "blank page" to "document ready for review," not to remove the review.
Practical example: Ahead of a filing deadline, the system generates a full draft disclosure — GHG figures pulled from Layer 1's dataset, mapped to the correct framework via Layer 3, formatted against the current requirement set from Layer 2 — and separately flags, say, that Scope 3 category 4 (upstream transportation) has data for only 60% of suppliers, with the rest estimated. A sustainability lead reviews the flagged gaps, decides whether estimation is acceptable or whether specific suppliers need to be chased, and signs off. The system did the compilation; a person made the judgment call that matters for assurance.
Why this framing matters more than the tools themselves
None of these four layers requires a single monolithic platform — they're a way of thinking about where automation adds value versus where a person's judgment is load-bearing. That distinction is what makes the system resilient to the kind of regulatory instability we've seen over the past two years. When Singapore delays a threshold, only Layer 2 needs updating. When you enter a new market, Layer 3 gets a new mapping, not a new project. When a supplier's data quality improves, Layer 1 absorbs it automatically.
Compare that to the spreadsheet-and-one-person model, where every one of those changes means starting a meaningful chunk of the work over. For an organization without a dedicated ESG team, that difference isn't incremental — it's the difference between reporting being a recurring fire drill and reporting being something the organization can actually keep up with.