The challenge
SECR-compliant reporting needs energy and emissions figures that can be traced back to evidence. For a UK SME, that evidence is rarely missing, but it is scattered. It sits in supplier invoices and accounting systems, in formats designed for paying bills, not for measuring carbon.
Turning that into a credible emissions figure by hand is slow and easy to get wrong. Someone has to find the relevant invoices, pull out the quantities, map each one to the right emissions category and apply the right conversion factor for the right year. Published emission factors change over time, so a report also has to show which factors were used, or it cannot be checked later.
- Read invoices in whatever format suppliers send them
- Pull accounting data directly from Xero, QuickBooks and Sage
- Calculate Scope 1, 2 and 3 emissions consistently
- Keep every figure traceable to its source and to the emission factor used
- Produce reports that are SECR-compliant and audit-ready
What I built
I designed Carbon-Passport as an ingestion pipeline feeding a calculation layer, with two routes in. Documents go through OCR with AWS Textract, which extracts the text and fields from invoices. Accounting data comes through Apideck, which gives one integration across Xero, QuickBooks and Sage instead of three separate ones. A unified accounting API was a practical choice: it lets the product support the systems SMEs actually use without maintaining a bespoke connector for each.
Both routes end in the same place: activity data in PostgreSQL, ready for calculation. The calculation layer maps that activity to Scope 1–3 categories and applies emission factors from DESNZ and the EPA. The factors are versioned, so every calculation records exactly which factor set it used. That matters for audit. When a figure is questioned later, you can show how it was produced, even after the published factors have been updated.
The backend is Python and FastAPI, which suits a product built around document processing, data integration and calculation. The front end is Next.js, where businesses connect their data and get their Carbon Passport reports. The platform runs on AWS, alongside the Textract OCR service it depends on.
The design principle throughout was traceability. A carbon figure is only useful to an SME if it holds up when an auditor, a lender or a customer asks where it came from, so every number in a Carbon Passport is built to be traced back to a document or a ledger entry and a specific emission factor.
Architecture and stack
- Front end
- Next.js
- Backend
- Python · FastAPI · PostgreSQL
- Ingestion
- AWS Textract (OCR) · Apideck · Xero · QuickBooks · Sage
- Calculation & reporting
- Scope 1–3 emissions · Versioned DESNZ/EPA emission factors · SECR-ready reports
- Cloud
- AWS
Outcome
UK SMEs can generate an audit-ready Carbon Passport from the invoices and accounting records they already keep. The manual work of collecting documents, keying in quantities and looking up conversion factors is replaced by a pipeline that does the extraction and the calculation the same way every time.
Because factors are versioned and each figure traces back to its source, the reports are built to be checked, not just read. That is the difference between a carbon number and a carbon number that stands up when someone asks for the evidence.
It also turns carbon reporting from a one-off project into something an SME can repeat each reporting period with the same method and a clear record of the factors behind it, which is what makes one year’s figures comparable with the next.
- SECR-compliant, audit-ready reports from existing data
- Invoices read by OCR, accounting data synced from Xero, QuickBooks and Sage
- Scope 1–3 calculations with a clear record of which emission factors were used
- A repeatable process instead of a manual reporting exercise
Last updated 2026-10-03