SmartBalance

SmartBalance is Carboledger's ISCC mass balance compliance platform built for supply chain companies (chemical manufacturers, biofuel traders, palm oil refineries, and plastic recyclers) who are legally required to maintain certified records of how sustainable materials move through their operations. I designed it from the ground up, starting with no product, no design reference, and a domain that most designers would not go near.

The core problem was not a UI problem. It was a domain translation problem. ISCC mass balance bookkeeping requires tracking certified inputs and outputs across thousands of SKUs, running complex calculations, maintaining chain-of-custody records, and producing audit-ready documentation, all while staying within a strict regulatory framework most users had only partially understood. The users were doing this entirely in Excel, which meant errors accumulated silently, audits failed unexpectedly, and compliance managers spent weeks preparing documentation that should have taken hours.

My job was to absorb a domain no product had properly digitised before, and turn it into something a trader or compliance manager could operate confidently without needing to hold the entire regulatory framework in their head.

Two distinct user types anchored the product, and understanding both was essential before touching any design decision.

Traders handled the day-to-day operational layer: recording incoming and outgoing certified materials, maintaining inventory balances, and generating sustainability declarations (SDs) for each transaction. Their work was high-volume, time-sensitive, and deeply prone to error when done manually. A single miscalculation in a mass balance record could cascade into an audit failure months later. They were not compliance experts, they were operations people forced to operate like compliance experts because no tool existed to separate those responsibilities cleanly.

Compliance Managers sat above the daily operations and owned the audit readiness of the organisation. They needed visibility across all transactions, the ability to verify that claims were accurate, and confidence that when an auditor arrived, every record would hold up. Their fear was not the daily data entry, it was the audit call they could not prepare for because the data across their team was inconsistent, incomplete, or locked in someone else's spreadsheet.

Both users shared one fundamental pain: the existing workflow required them to maintain records manually in Excel while simultaneously running regulatory calculations and keeping thousands of SKUs in mind. There was no single source of truth, no automated validation, and no way to know you had made an error until an auditor told you.

Before designing anything I had to understand ISCC mass balance well enough to make product decisions, not just surface-level enough to sketch wireframes. This took longer than any other phase and was the most consequential investment I made on the project.

I started with the ISCC documentation itself, reading the actual certification standards and understanding how mass balance works as an accounting method for sustainable materials. Mass balance is not physical tracking, it is a system of bookkeeping where certified and non-certified material can be mixed physically as long as the certified volumes are accurately accounted for at each step. Getting that distinction wrong would have meant designing a system that looked correct but violated the underlying regulatory logic.

Beyond the documentation I talked directly with domain experts and independent auditors who review ISCC-certified companies. These conversations gave me something the documentation could not: an understanding of where companies actually fail. Audit failures are rarely about malicious intent, they are about record gaps, inconsistent unit conversions, and missing documentation that the company never knew it needed. That insight shaped what the product needed to enforce versus merely suggest.

I also ran discovery and demo calls with prospective clients who became design partners. These were the actual traders and compliance managers who would use the product. Watching how they worked in Excel, asking them to walk me through a real mass balance cycle, and listening to where they expressed confusion or anxiety gave me a ground-level map of the cognitive load the product had to absorb.

There was no existing product solving this problem in the market. That meant no competitive reference, no established UX pattern to borrow from, and no user expectation to anchor on. Every decision had to come from first principles.

The first version of the information architecture was wrong in a way that only became clear once real users tried to work with it.

Our initial understanding of how traders handled inventory and unit calculations did not match how the actual regulatory workflow operated. ISCC mass balance involves conversion factors, different unit types across input and output materials, and specific rules for how certified volumes are allocated across products. We had modelled the data structure and the UI around a simplified version of this that made internal sense but broke down the moment a user tried to complete a real booking cycle.

Users pushed back directly. They could not reconcile what they were entering in the system with what they knew the audit would require. We had to go back to the domain, re-examine the calculation logic, and rebuild the information architecture from a more accurate foundation. This happened more than once. Each iteration brought the product closer to the regulatory reality users were living in, and further from the clean, simplified model we had started with.

This was the most important design lesson from the project. Complexity that exists in the domain cannot be designed away, it can only be structured. The goal is not to hide the complexity from users but to ensure they encounter it in the right sequence, with the right guardrails, so they can make accurate decisions without holding the entire rulebook in their head simultaneously.

Translating regulatory logic into product primitives

The central design challenge was deciding which regulatory concepts needed to be explicitly visible to users and which could be handled invisibly by the system. Mass balance calculations, for example, needed to be automated entirely. A trader should never have to manually compute whether their certified output volume is within allowable limits. But the inputs driving those calculations needed to be visible and editable, because auditors would ask about them.

This meant designing a system where the calculation layer was abstracted but the data layer was always accessible and auditable. Every record needed a traceable source. Every number on screen needed to connect back to a document or a transaction. The UI had to make this chain visible without making it overwhelming.

Multi-site and multi-SKU scale

High-volume traders were managing thousands of SKUs across multiple sites simultaneously. A design that worked for 20 products would collapse under the cognitive weight of 2,000. This meant the information architecture had to support bulk operations, clear filtering, and a structure where users could orient themselves quickly across large datasets without losing track of where a specific record sat within the compliance picture.

AI-powered sustainability declaration parsing

Sustainability declarations (SDs) are the documents that certify a material's origin and compliance status. Under the manual workflow, a trader receiving an SD had to open it, read it, and manually enter all relevant data fields into their records. A single SD could take one to two hours to process. Traders receiving hundreds of SDs per month were losing weeks to data entry alone.

I designed the AI document parsing flow to eliminate this entirely. Users could upload PDF sustainability declarations in bulk, and the system would extract, parse, and populate the relevant data fields automatically. What previously took one to two hours per document now took seconds, regardless of volume. The improvement was 10x in processing speed, and more importantly, it removed a category of manual error that had been a consistent source of audit risk.

The design challenge here was not the AI itself but the verification layer around it. Users needed to trust the extracted data, which meant the interface had to make it easy to review what the AI had parsed before committing it to their records. The flow was designed so that extracted data was always surfaced for confirmation, with clear indicators of confidence and easy correction for edge cases.

The 10x improvement in SD processing speed was the most direct and measurable outcome from the design work. Reducing a one to two hour manual task to seconds per document, at any volume, fundamentally changed what was operationally possible for high-volume traders.

Beyond speed, the platform gave compliance managers something the spreadsheet workflow never could: a single, auditable source of truth across all transactions and sites. Audit preparation, which had previously required assembling records from scattered spreadsheets across multiple team members, became a report generation task rather than a data reconciliation exercise.

Carboledger now serves enterprises including Fortune 100 companies, across industries ranging from specialty chemicals to palm oil to plastic recycling, operating across multiple global markets including the US, UK, Malaysia, Indonesia, and Brazil.