From Field to Finance: The Complete Emissions Data Journey

Every carbon report is a story of data transformation. It starts as a field worker's photograph of a waste ticket. It becomes OCR-extracted numbers. It gets reviewed by a sustainability manager. It's calculated by a mathematical formula. It's aggregated with other data. It's frozen in an immutable snapshot. Finally, it's published as a board-ready report.

Each step is an opportunity for errors to slip in. Most platforms handle one or two steps well. CarbonSite designed every step to catch and prevent errors.

The Data Journey: Five Stages

Stage 1: Capture (Field Worker)

A field worker photographs a waste ticket. The ticket shows: "2,450 kg, plastic waste, Jan 15, 2026"

Possible errors at this stage:

• Photo is blurry (can't read the numbers)
• Wrong document photographed (photo contains invoice instead of waste ticket)
• Incomplete information (date missing, category unclear)

CarbonSite prevents these with:

• Image quality checks: If photo is too blurry, app prompts to retake
• Document classification: App confirms "This looks like a waste ticket" before proceeding
• Completeness validation: Field app flags missing fields before submission

Stage 2: Extraction (OCR)

OCR extracts structured data from the photograph. Expected result: {weight: 2450, unit: "kg", category: "plastic waste", date: "2026-01-15"}

Possible errors:

• "2,450" misread as "24,50" or "2450" with wrong unit
• Category text recognized as "plastic waste" but system doesn't recognize this specific category name
• Date format misread (Jan 15 → 15 Jan → different interpretation)

CarbonSite prevents these with:

• Regex validation: Weight extraction requires explicit unit matching
• Category mapping: OCR result matched against canonical categories; unclear matches require review
• Date normalization: Multiple date formats handled; normalized to ISO 8601

Stage 3: Review (Sustainability Manager)

A sustainability manager reviews the extracted data and the original photo.

Review flow:

1. See OCR result: {weight: 2450, unit: "kg", category: "plastic waste"}
2. See original photo to verify
3. Approve (OCR was correct), Correct (OCR had error), or Reject (entire submission is wrong)

Possible errors:

• Manager fat-fingers a correction: "2450" → "2450" (typo, 24.50 meant)
• Manager approves OCR error: "24,50" actually was "2,450" but reviewer missed it
• Manager corrects based on memory, not photo: "The ticket said plastic but I remember it was paper"

CarbonSite prevents these with:

• Visual confirmation: Original photo shown side-by-side with extracted data
• Audit trail: Who reviewed it, when, what changed
• Anomaly detection: If corrected value is 100x different from baseline, flag for second review
• Edit history: All corrections logged with reason

Stage 4: Calculation (Engine)

The calculation engine applies emission factors:

Input: {weight: 2450 kg, category: "plastic waste"} Factor: 2.8 kg CO2e per kg (plastic waste to landfill) Result: 2450 × 2.8 = 6,860 kg CO2e

Possible errors:

• Wrong factor selected (applied factor for plastic incineration instead of landfill)
• Factor not updated (using 2024 factor instead of 2025 factor)
• Calculation error (arithmetic mistake)
• Unit conversion error (forgot to convert kg to tonnes)

CarbonSite prevents these with:

• Factor selection logic: Deterministic, documented, reproducible. Same data always gets same factor.
• Factor versioning: Factors tied to methodology version. Can see exactly which factor was used.
• Formula storage: Formula captured with result. Easy to verify: 2450 × 2.8 = 6,860 ✓
• Unit system: Canonical units system. All conversions automated and checked.

Stage 5: Publication (Report)

Calculated emissions are frozen into an immutable snapshot and published.

Snapshot shows:

• Total emissions: 1,234,567 kg CO2e
• Methodology version: ghg-protocol-v2026-01
• Calculation timestamp
• Data completeness (80% of expected records captured)

Possible errors:

• Report published with wrong time period (Dec instead of Jan)
• Calculation methodology changed mid-stream (v2026-01 vs v2026-02)
• Some data was excluded by accident

CarbonSite prevents these with:

• Snapshot immutability: Once published, snapshot can't be changed
• Methodology versioning: Every snapshot records which methodology was used
• Data lineage: Snapshot shows: "50,000 records included, 10,000 pending review, 5,000 failed quality checks"
• Recalculation versioning: If errors found and corrected, new snapshot created (v2) with clear change history

Error Recovery Workflow

If an error is discovered at any stage, CarbonSite's workflow is:

1. Identify — Which stage failed? (OCR, review, calculation, publication)
2. Correct — Fix the source data or explanation
3. Recalculate — Rerun calculation from corrected data
4. Version — Create new snapshot, document change
5. Notify — Auditors and stakeholders see the change history

This is different from systems that silently update calculations. You get an audit trail showing: "Calculated Jan 15 with error X. Corrected Jan 20. Recalculated with corrected data."

Real Example: Catching a Calculation Error

January publication:

• Field worker captures 50 tonnes waste
• Sustainability manager approves
• Engine calculates: 50 × 2.8 = 140 kg CO2e
• Snapshot published: 140 kg CO2e

July audit:

• Auditor reviews the calculation
• Auditor notices: factor should be 2.80 kg CO2e per kg, not 0.28 per 10 kg
• Previous calculation used wrong factor version (old 2024 factor instead of new 2025 factor)
• True emissions should be: 50 × 2.80 = 140 kg CO2e (actually same result, but methodology was wrong)

CarbonSite handles this:

1. Audit finds error in factor selection
2. Sustainability team updates factor library to 2025 version for January period
3. System recalculates: 50 × 2.80 = 140 kg CO2e (same result)
4. Creates new snapshot (v1.1) with note: "Corrected factor library reference (Jan 15 → Jul 20). Calculation unchanged."
5. Audit trail shows: v1.0 (Jan 15, wrong factor), v1.1 (Jul 20, corrected factor, same result)

Auditor can see the entire history. No mystery. No "we hope this was right."

The Key: Design for Verification

Most platforms optimize for convenience: easy data entry, pretty dashboards, fast reports.

CarbonSite optimizes for verification. Every step is designed so auditors can ask "How did you get this number?" and you can show them the complete path:

1. Original photo (field capture)
2. OCR extraction and review (data entry)
3. Factor selection and formula (calculation)
4. Immutable snapshot (publication)
5. Audit trail of any corrections (changes)

This is what carbon accounting should look like.