An ESG director we spoke with recently described her company’s carbon procurement stack in one sentence: “We have a spreadsheet that tells us what we bought, and a prayer that it holds up in an audit.” That sentence is about to become a liability. With the Science Based Targets initiative’s Corporate Net-Zero Standard V2.0 now formally recognizing commodity certificates, book-and-claim chains of custody, and a new category called Ongoing Emissions Responsibility, the flat, undifferentiated ledger most corporate carbon teams rely on is structurally unequipped for what auditors are about to ask. This post is about why a purpose-built book-and-claim carbon credit platform is no longer a nice-to-have for enterprises navigating V2.0, and what it actually takes to engineer one at the data layer, not just the reporting layer.
For most of the last decade, corporate carbon procurement tools have treated every credit the same way: an ID, a quantity, a vintage, a status of “retired” or “available.” That model was tolerable when the primary use case was voluntary offsetting against a single, simple claim. It is not tolerable anymore.
SBTi’s Corporate Net-Zero Standard V2.0 introduces an implementation hierarchy that requires companies to distinguish between multiple, legally distinct instrument categories operating under different rules simultaneously. Commodity certificates and energy attribute certificates using mass balance or book-and-claim chains of custody are now formally recognized as legitimate implementation tools for certain scope 3 categories, but they are reported separately from the physical emissions inventory and must meet specific integrity criteria around activity matching and double-counting prevention. Separately, the standard introduces Ongoing Emissions Responsibility, a mechanism addressing the years a company continues emitting while working toward its target, which large companies must engage with formally from 2035 or disclose why they haven’t.
A book-and-claim carbon credit platform has to hold all of this simultaneously: physical inventory data, decoupled environmental attribute certificates, neutralization-grade removal credits, and OER-eligible instruments, each governed by different eligibility rules, each needing to be queried, filtered, and reported on independently without contaminating the others. Treat these as one undifferentiated pile of “carbon credits,” and a compliance audit will find the gap immediately.
Most transaction ledgers, whether in a traditional database or a basic blockchain implementation, are built around a linear delivery model: an asset exists, it moves from party A to party B, and its state changes from “held” to “transferred.” That model works fine for a physical bar of gold or a single share of stock. It breaks down the moment you introduce book-and-claim.
Book-and-claim, by definition, separates the environmental attribute of a low-carbon commodity from the physical product it describes. A sustainable aviation fuel certificate, for instance, can be sold, tracked, and retired entirely independently of the physical fuel itself, which may be consumed thousands of miles away by a party with no contractual relationship to the certificate buyer. A linear ledger has nowhere to put that split. It wants one asset, one owner, one location. Book-and-claim wants two parallel records — a physical delivery record and an attribute record that are related but never merged, and that can be independently audited, retired, and reported without either one silently inheriting the other’s status.
This is the architecture problem a book-and-claim carbon credit platform actually has to solve: not “how do we record a transfer,” but “how do we record two distinct, cryptographically traceable claims against a single originating event, without ever letting them be double-counted against the same target.”
The fix is not a bigger spreadsheet or a more detailed status field bolted onto an existing table. It’s a fundamentally different data model one where every credit or certificate is described not by a single status flag, but by a structured set of attributes that a query engine can filter against instantly.
In practice, this means moving to a schema built around highly structured attribute storage, using an approach like JSON-B fields layered on top of relational tables with dedicated micro-indexes on the fields that compliance teams and auditors will query most often. Rather than a single “credit_status” column, each unit in a book-and-claim carbon credit platform carries a structured attribute object that can include:
The engineering value of this approach is that these attributes live at the data layer, indexed and queryable, not buried in a PDF certificate or a manually maintained tag in a spreadsheet. When a compliance officer needs to pull every OER-eligible, Advanced-tier, book-and-claim certificate purchased in a given reporting year, that should be a sub-second, indexed database query, not a week of manual document review before an audit deadline.
One of the more quietly dangerous failure points in legacy carbon ledgers is treating permanence as an afterthought, something noted in a project description rather than something the platform actively enforces. Under V2.0’s durability requirements, this distinction is not cosmetic. A company matching residual emissions against removals needs those removals to carry a storage duration genuinely comparable to the atmospheric lifetime of the emissions being addressed, and the standard proposes either a like-for-like matching approach or a phased transition toward more durable removals through 2050.
A book-and-claim carbon credit platform designed for this reality doesn’t just store a “credit type” label. It structurally isolates permanent removal inventory from temporary reduction inventory at the query layer, so that a reporting dashboard, an API call, or an internal override cannot accidentally pull a temporary nature-based credit into a bucket that a company’s climate transition plan has designated for permanent removal matching. This is the same design principle that governs how we’ve approached credit-state architecture on Carbon Plant, our FSA-registered environmental impact exchange: state and category distinctions have to be enforced at the data and settlement layer, not left to a front-end filter that a direct API call can simply bypass.
To be clear about scope: this kind of layered tagging and category isolation is the same architectural discipline behind the compliance-aware asset tagging already built into Carbon Plant’s registry and exchange infrastructure for our existing clients. What SBTi V2.0 changes is the specific taxonomy recognition tiers, OER eligibility, and book-and-claim decoupling that a platform now needs to tag against. We are not claiming this exact SBTi V2.0 schema has been built and deployed for a client yet; we’re describing the architecture required to build it correctly, and it’s a natural extension of infrastructure we already operate.
OER deserves its own section because it is the part of V2.0 most likely to catch procurement teams off guard. It isn’t a target-year mechanism like neutralization. It’s a disclosure obligation about the emissions a company continues to produce, year over year, while still working toward its long-term target and large companies will need to either engage with it formally from 2035 or explicitly disclose why they have chosen not to.
For a data platform, this means OER can’t simply be folded into the same reporting bucket as neutralization credits or removal purchases. It needs its own tagged category, its own eligibility rules, and its own audit trail, because a company’s OER position and its neutralization position answer two different questions for two different audiences: one is about ongoing operational responsibility, the other is about closing the gap on a long-term target. A book-and-claim carbon credit platform that conflates the two isn’t just sloppy. It hands an auditor or an NGO researcher a very easy story to tell about greenwashing.
Structurally, this means OER-eligible instruments need a dedicated tag at the point of ingestion, a separate reporting query path, and a retirement record that’s distinguishable from a neutralization retirement the moment someone pulls the ledger. That is a data modeling decision made at day one of platform design, not something you can retrofit gracefully six months after your first audit cycle under the new standard.
If you operate a carbon exchange, a registry, or an internal corporate carbon desk, V2.0 changes what “audit-ready” actually means. A flat ledger that can tell you what you bought is no longer sufficient. You need infrastructure that can tell you, on demand, which category a unit belongs to, which SBTi tier it aligns with, whether it’s permanent or temporary, and whether it’s eligible for OER disclosure or neutralization reporting — all without a manual reconciliation project every time a board member or auditor asks a specific question.
This is precisely the kind of multi-modal ledger architecture we build at Techaroha for climate fintech builders, carbon fund managers, and compliance-grade exchange operators. A well-engineered book-and-claim carbon credit platform turns audit prep from a scramble into a query. If your current platform, whether internally built or licensed, can’t answer “show me every OER-eligible, Advanced-tier certificate in our portfolio” with a single indexed query, that’s not a reporting gap. It’s an architecture gap, and it’s worth a conversation before your next audit cycle, not during it.
For carbon fund managers evaluating a new book-and-claim carbon credit platform, or exchange founders assessing whether their existing stack can support V2.0’s category requirements, the decision point is the same one every technical audit eventually reaches: was this schema designed for this taxonomy from the start, or patched together after the fact. A book-and-claim carbon credit platform built on the multi-layered attribute model described above is designed for the former.
