On a carbon accountant's screen are forty supplier responses, and no two look alike. One is a tidy spreadsheet with a header row in German. One is a scanned PDF of a methodology memo with the number she needs buried in a footnote. One is a three-line email that says "around 4,500 t, same basis as last year." One is a procurement contact forwarding a supplier's brochure with a hopeful note. Somewhere in this pile are the activity figures that will become a fifth of her Scope 3 inventory, and the inventory is an assured figure: an external auditor will pull a sample and ask, of any datapoint, "which supplier, which period, what value, what unit, is this measured or estimated, and where is the source file." If she cannot answer that for every number, the figure is not defensible. Parsing is the step that turns this heterogeneous pile into structured records that can answer those questions. And the thing that makes those records assurable is not the value she extracts. It is the provenance she preserves on every datapoint.

Provenance Is the Product, Not the Value

It is tempting to think the job of parsing is to get the number out of the document. It is not. A number with no provenance is worthless in an assured inventory, because the assurer cannot test it, and an untestable number is a liability rather than an asset. The actual product of parsing is a complete, traceable record: the value, yes, but bound permanently to the metadata that lets someone reconstruct and check it. Provenance is that binding, the unbroken thread from a published or inventory figure back to the specific evidence it came from. In disclosure, provenance is what makes a number assurable; without it you have an assertion, with it you have evidence.

So before we talk about AI at all, fix the target. Every datapoint that comes out of a supplier response should carry, at minimum, six fields. The supplier it came from, named and identifiable. The reporting period the figure covers, because a number for the wrong year silently corrupts a trend. The value itself. The unit, stated explicitly, because a value without a unit is not data. The tier, primary or secondary, recording whether this is supplier-measured activity data or an estimate, because an assurer treats the two differently and they must never look identical in the file. And the source file, a pointer to the exact document, and ideally the exact location within it, that the figure was read from, so a stranger can open the file and see the number with their own eyes. Six fields. Get the value without the other five and you have not done the job; you have created a number nobody can defend.

You care about each field for a specific assurance reason. Supplier and period let the assurer trace and re-perform. Unit prevents the silent order-of-magnitude error that comes from kilograms read as tonnes. Tier protects the primary-data share the assurer probes. And the source-file pointer is the single most important field, because it is the thread itself: it is the difference between "the supplier told us 4,500 tonnes" and "here, in this PDF, on this page, is where the supplier told us 4,500 tonnes." The first is hearsay. The second is evidence.

Why Parsing Is Hard, and Where AI Fits

Parsing is hard precisely because supplier responses are heterogeneous and the important metadata is scattered, implicit, or in another language. The value might be in a spreadsheet cell, a PDF table, an email sentence, or an attachment to an attachment. The unit might be in a column header three rows up, or omitted entirely. The period might be in the email subject line, in a cover note, or assumed. The tier might be stated plainly, hinted at ("estimated using sector data"), or absent. Doing this by hand across hundreds of suppliers is slow and produces inconsistent records, because a tired human formats datapoint 200 differently from datapoint 2.

This is genuinely where AI helps, because extraction and structuring across messy, multi-format documents is one of the tasks the technology does well. A model can read a German spreadsheet, an English email, and a scanned memo and propose, for each, a structured record with the six fields populated. It can normalise wildly different layouts into one consistent shape that a reporting system will accept. It can flag where a field is missing rather than leaving the gap silent. What takes a human a week of inconsistent copy-paste, AI can draft in an afternoon, in a uniform structure, with the missing fields marked. That is real, and it is the reason this step is in the goldmine.

The Source Pointer Is the Non-Negotiable Field

But there is a sharp line that separates assurable AI parsing from dangerous AI parsing, and it runs straight through the source-file field. When a model extracts a value, it must also record where it read it: this file, this sheet or page, this cell or line. The reason is that a generative model can produce a beautifully structured record for a number that is not actually in the document, because producing plausible structured text is exactly what it does. If the record says "supplier X, 2025, 4,500 tonnes CO2e, primary" but carries no pointer to where that came from, you cannot tell whether the model read it or invented it. The source pointer is what makes the extraction checkable. With it, a human can open the file and confirm the number in seconds. Without it, the record is an unverifiable claim that looks identical to a real one, which is the most dangerous artifact in the whole pipeline. Never accept an extracted datapoint that cannot say where it came from.

The product of parsing is not the number. It is the number bound to its proof: supplier, period, value, unit, tier, and the exact source file. Strip the proof and you have not extracted data, you have manufactured an assertion.

Tagging the Tier Without Laundering It

Of the six fields, the tier is the one AI is most likely to corrupt, and it corrupts it in a specific, quiet way: by smoothing. A supplier writes a long, hedged email: "we don't meter this line directly, so we've estimated it from sector averages, roughly 4,500 tonnes." A model asked to extract the figure will happily return "4,500 tonnes CO2e, primary" or simply "4,500 tonnes CO2e" with no tier, because the clean number is what it was reaching for and the hedge was noise to be discarded. The supplier told you plainly it was an estimate; the parsed record now says, or implies, that it was measured. That is laundering, and it inflates your primary-data share with a figure the assurer will catch the moment they read the original email.

The discipline is to make the tier a required, evidence-backed field, not an inference. The parsed record should carry the supplier's own statement of basis, ideally quoted, so the tier is grounded in what the supplier actually said rather than what the model assumed. If the supplier said "estimated from sector averages," the record says secondary, basis: supplier estimate from sector averages, and points to the sentence. If the supplier gave a metered figure with a meter reference, the record says primary, basis: supplier-metered, and points to it. If the supplier said nothing about basis, the record says tier: unknown, flagged for follow-up, never a silent default to primary. The rule is simple and absolute: the model may propose the tier, but the tier must be backed by the supplier's own words in the source, and an unbacked tier is a gap, not a measurement.

A Worked Example: One Messy Response, Two Parses

A supplier, a packaging manufacturer, sends a two-paragraph email. The relevant content: "For calendar year 2025, the carbon footprint of the products we supplied to you was approximately 4,500 tonnes CO2e. We don't have direct metering at the product level, so this is estimated using our sector's average emissions intensity applied to the volume you purchased. Happy to share our methodology note (attached) on request." The methodology note is attached as a PDF. Watch two parses.

Before (the laundered extraction): The analyst asks AI to "pull the emissions figure from this supplier email." The model returns a clean record: Supplier: PackCo; Value: 4,500; Unit: tCO2e; Tier: primary. It looks perfect and ingests neatly into the reporting system. But it has silently dropped the period into an assumption, omitted the unit's confirmation, asserted primary when the supplier plainly said estimated, and carried no pointer to the email or the methodology PDF. Months later the assurer reads the original email, sees "estimated using sector average," and now has a finding: a secondary figure recorded as primary, with no source pointer, on a datapoint that is part of a fifth of the inventory. The clean record was worse than no record, because it laundered an estimate into a measurement and erased its own trail.

After (the provenance-preserving extraction): The analyst instructs the model to extract the figure with all six fields and to back the tier with the supplier's own words. The model returns: Supplier: PackCo; Period: CY2025; Value: 4,500; Unit: tCO2e; Tier: secondary (estimate); Basis: "estimated using sector average emissions intensity applied to purchased volume" (supplier's words); Source: PackCo_response_email, paragraph 1; Supporting: PackCo_methodology_note.pdf, attached. Every field is populated, the tier is correctly secondary and grounded in the supplier's quoted statement, and there are pointers to the exact email paragraph and the supporting PDF. When the assurer samples this datapoint, the analyst opens the email, shows the sentence, shows the methodology note, and the figure stands as a properly labelled, fully traced secondary estimate. Same email, same 4,500 tonnes. One parse produced a finding; the other produced evidence.

The entire difference is provenance. Not a better number, not a different value, but the six fields preserved and the tier backed by the source. The first parse threw away everything that made the number testable and got the tier wrong in the bargain; the second kept the thread intact from the inventory line back to the supplier's own sentence.

From Records to a Structure the System and Assurer Both Accept

The final piece is shape. The reporting platform needs records in a consistent structure to ingest them, and the assurer needs that same structure to read the lineage, so the two requirements coincide. Parsed datapoints should land in a uniform schema, the same six fields in the same order for every supplier, so that record 2 and record 200 are formatted identically and the dataset is machine-readable rather than a pile of prose. AI is good at producing this uniformity, which is part of its value here: it can take forty differently-shaped responses and emit forty identically-shaped records.

The caution is that uniformity is seductive and can hide missing evidence. A dataset where every record has the same neat columns can look complete even when half the source-file pointers are blank or half the tiers are unbacked guesses. So the structure must make absence visible, not paper over it. A missing unit is an empty unit field flagged, not a silently assumed default. A missing source pointer is a record marked unverifiable, not a record that looks like the others. An unbacked tier is tier: unknown, flagged, not a quiet primary. The schema's job is to carry the provenance and to make the holes in the provenance impossible to miss, so that the analyst confirms each record against its source before it becomes part of the inventory. A clean schema with hidden gaps is the laundered fill of the parsing world; a clean schema that surfaces its own gaps is the instrument that makes the next stages, gap-flagging and accountability, possible.

Format and Language Do Not Change the Rules

A supplier response can arrive as a polished spreadsheet, a scanned PDF, a forwarded email chain, or a photographed document, and in any language your value chain speaks, and it is tempting to think each format needs its own special handling. It does not, at the level that matters. The six fields and the source pointer are required regardless of format, and the harder the format is to read, the more the source pointer earns its place, because a number lifted from a blurry scan or translated from another language is exactly the kind of figure an assurer will want to trace back and see in its original form. A clean spreadsheet cell and a translated footnote both produce a record with the same six fields; what differs is only how much confirmation the human owes the extraction before trusting it.

Two format-specific cautions are worth naming. With scanned or photographed documents, the model is reading an image, and optical recognition can misread a digit or a unit, turning a 7 into a 1 or kg into t, so the source pointer to the exact image location is what lets a human confirm the reading against the original. With translated responses, the meaning of the basis statement can shift in translation, and the tier rides on that meaning, so the parsed record should keep the supplier's original-language statement of basis alongside the translation, so the assurer can see the actual words rather than a paraphrase that may have softened "estimated" into something vaguer. In both cases the principle is the same as the rest of the lesson: the format may make extraction harder, but it never lowers the standard, and the source pointer is what carries the difficulty without lowering the bar.

Working Rules for Parsing Into Tagged Data

A handful of rules keep parsing on the assurable side. Treat provenance as the product, not the value: a number without its six fields is not a datapoint, it is an unverifiable assertion. Require all six fields on every record, supplier, period, value, unit, tier, and source file, and treat any missing field as a flagged gap rather than a silent default. Make the source-file pointer non-negotiable, because it is the thread that makes the extraction checkable, and never accept an extracted figure that cannot say where it came from. Back the tier with the supplier's own words, quoting the basis, so the primary-or-secondary tag is grounded in evidence rather than inferred, and let an unstated basis be tier: unknown rather than a default to primary. Treat every AI-extracted record as a proposal to confirm against the source, not a record to trust, because a model can produce a flawless-looking record for a number that is not in the document. Land records in a uniform schema so the system can ingest them and the assurer can read the lineage, but design the schema to make missing evidence visible rather than hidden. Follow these and parsing turns a heterogeneous pile of supplier correspondence into traced, tagged, assurable inventory inputs. Ignore them and AI turns the same pile into a tidy, uniform, indefensible dataset that fails the moment an assurer opens one source file.

Key Takeaways

• The product of parsing is not the extracted value but the value bound to its provenance; a number without provenance is an unverifiable assertion, not an assurable datapoint.
• Every parsed datapoint must carry six fields: supplier, reporting period, value, unit, primary-or-secondary tier, and source file, ideally with the exact location within it.
• AI genuinely helps because extraction and structuring across heterogeneous, multi-format, multi-language responses is a task it does well, turning a week of inconsistent copy-paste into an afternoon of uniform records.
• The source-file pointer is the non-negotiable field, because it is the thread that makes the extraction checkable; a record with no pointer cannot be distinguished from an invented one.
• The tier is the field AI most often corrupts, by smoothing a hedged estimate into a clean primary figure; the fix is to back the tier with the supplier's own quoted statement of basis.
• An unstated basis must become tier: unknown, flagged for follow-up, never a silent default to primary, because a default to primary inflates the primary-data share the assurer probes.
• Every AI-extracted record is a proposal to confirm against the source, because a model can produce a flawless-looking record for a number that is not actually in the document.
• Records should land in a uniform schema the system can ingest and the assurer can read, but the schema must make missing evidence visible rather than papering over it with neat empty columns.