A Korean electronics exporter met the first CBAM quarter without filing delays — and modelled EUR 280k of penalty savings

What they had before

The customer is a Korean consumer-electronics exporter with EUR 180 million of annual EU revenue across eleven importers in Germany, the Netherlands, and Poland. Their finished goods — flat-panel displays, small appliances, smart-home hubs — ship in product casings that contain non-trivial fractions of steel and, in two SKU lines, cement-bonded shielding. When CBAM widened from the transitional period into the definitive period on 1 January 2026, those embedded materials brought the shipments into scope alongside the more obvious primary-steel CBAM lines.

The operational problem hit immediately. EU importers needed embedded emissions documentation per shipment for their own CBAM filings, including the transport leg. Without it, the importer's default position is to apply the default emission factor, which CBAM explicitly designs to be punitive — the gap between actual and default factor maps directly to a higher carbon liability per tonne. Our customer's importers were not going to absorb that gap quietly; the conversation in late 2025 had already moved from "would be nice" to "we need this on every invoice or we renegotiate the contract."

Internally, the customer had nothing. The sustainability function was a one-person shop. The shipping platform was a homegrown system that wrapped a Cargowise integration on the forwarder side. There was no calculator, no factor library, no commercial-invoice template field for transport CO₂. The fallback plan — fill it in by hand per shipment — was modelled at fourteen days per shipment before customs release and would have collapsed the quote-to-ship cycle.

What changed

We embedded the EcoFreight API inside the customer's shipping platform via a server-side service the platform already used for rate-card lookups. On every shipment, after the carrier and route are confirmed, the service calls POST /api/v1/calculate with the GLEC Framework v3.2 factor set and the WTW scope. The returned co2e_kg, distance_km, and data_quality_tier are persisted on the shipment record and then templated into the commercial invoice PDF in the section the importer's CBAM filings reference.

The integration is plain HTTPS — no SDK, no broker — because the customer's shipping platform engineer wanted to keep the dependency surface narrow. Total engineering time from kickoff to first live invoice was about six engineering-weeks, two of which were the schema work to add the carbon line to the commercial invoice template in a way the importer's customs broker could read.

Three details mattered for CBAM specifically. First, we use the per-shipment WTW number, not a quarterly average — CBAM filings are per-import, so an average would not survive the filing. Second, the response includes the data_quality_tier field from the ISO 14083 tier policy, which the importer's customs broker now copies into their CBAM disclosure verbatim. Third, the calculation_id is persisted on both the shipment record and the invoice; when a CBAM filing is audited two years from now, that ID dereferences to the exact inputs, factor set, and engine version that produced the number. No silent recalculation.

Importer onboarding went mostly through the customer's existing account managers. Each importer received a one-page note explaining where on the commercial invoice the CO₂ line would appear, which methodology we used, and how to pull the calculation ID for the broker. Two importers' customs brokers needed a short call to align on the field; the other nine accepted the template on the first shipment.

The invoice field was deliberately plain: one WTW value in kg CO₂e, one distance value, one data-quality tier, and one calculation ID. We rejected a richer PDF layout because the broker teams were keying the data into their own CBAM systems. The fewer fields they had to interpret, the lower the filing-delay risk.

Where the numbers landed

The EUR 280k figure deserves an honest footnote. It is modelled, not banked. The calculation assumes the alternative was default-factor application on every transport leg through 2026; the customer's commercial team is comfortable that this was the realistic counterfactual. We would not call it "saved revenue" in clean accounting terms. We would call it a penalty the customer is not paying because the data is there.

What we would do differently

On the next CBAM-driven integration of this shape we would tighten one thing.

We would scope the broker-side integration at the same time as the shipper-side integration, even if we deliver it in a second phase. Asking the broker team to accept a PDF-based handoff for six months was the right tactical choice — go-live dates do not move — but it cost us a late-Q1 round of broker-side calls when two brokers wanted clarification on the data quality tier field. If the broker stack had been part of the original scope conversation, we would have flagged that field specifically in the initial onboarding note and saved roughly two engineering-days of follow-up.