The challenge
Most UK SMEs already hold the evidence a carbon report needs. Energy use and purchases show up on supplier invoices and in the accounting ledger. The difficulty is that none of it was recorded with emissions in mind. An invoice is laid out to be paid, and a ledger is organised for the finance team, so getting from either to a defensible Scope 1–3 figure takes real work.
Done by hand, that work has several failure points. Somebody gathers the documents, reads off quantities, decides which emissions category each belongs to and picks a conversion factor. DESNZ and the EPA publish updated factors over time, so unless the report records which set was applied, nobody can reproduce the figure later. For a business reporting under SECR, a number that cannot be reproduced is a weak number.
- Accept supplier invoices as they arrive, in whatever layout the supplier uses
- Connect to Xero, QuickBooks and Sage instead of asking for exports
- Apply one consistent method across Scope 1, 2 and 3
- Record the source document and factor set behind every figure
- Output reports that meet SECR and are ready for audit
Our approach
We split the product into two halves: getting data in, and doing the maths. Keeping them apart means the calculation rules can be reviewed on their own, without anyone needing to understand OCR or accounting APIs to check a result.
For data in, there are two paths. Supplier invoices go through AWS Textract, which pulls text and fields out of each document. Ledger data comes through Apideck, a unified accounting API that covers Xero, QuickBooks and Sage in one integration. We chose a unified API deliberately. SMEs use all three systems, and writing and maintaining three separate connectors would have taken time away from the part of the product that matters most, the calculations.
Both paths write activity data into PostgreSQL. The calculation layer then assigns each activity to Scope 1, 2 or 3 and applies DESNZ or EPA emission factors. We versioned the factor sets and stored the version against every calculation. When factors are republished, past reports stay reproducible, and a new report uses the new set openly instead of quietly rewriting history.
Python and FastAPI run the backend, which suits the document handling, integration and calculation work at the centre of this product. Businesses connect their accounts and receive their Carbon Passport through a Next.js front end, and the whole platform runs on AWS next to Textract.
Our advice to anyone building in this space: treat traceability as a feature from day one. Storing the source and the factor version as each figure is created is far easier than reconstructing them later, when a customer, lender or auditor questions a number.
Architecture & 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
The outcome
UK SMEs using Carbon-Passport can produce an audit-ready Carbon Passport from records they already keep. Gathering invoices, reading off quantities and finding the right factors is now handled by a pipeline that applies the same method each time.
Each figure in a report links back to an invoice or a ledger entry and to the factor set used, so questions about the numbers can be answered from the record itself.
Because the method and the factors are written down with every report, each reporting period can be run the same way as the last. That gives the business year-on-year figures it can compare with confidence.
- SECR-compliant reports built from data the business already holds
- OCR for supplier invoices, Apideck for Xero, QuickBooks and Sage
- Scope 1–3 figures tied to a recorded factor version
- The same method every reporting period
Last updated
