A European 3PL retired eight years of quarterly Excel — and won seven RFPs in the next cycle
Three Mediterranean ocean lanes, an Iberian road network, and eight years of quarterly DEFRA 2019 rollups in a single Excel workbook. We worked with the customer's sustainability lead and Blue Yonder team to plug per-shipment WTW emissions in under 50 ms p50 — and to keep the Excel running for two quarters of dual reconciliation while the auditor got comfortable.
Headline numbers
- Reporting lag: 8-10 weeks down to real-time on every shipment.
- Quarterly reporting effort: 2-5 person-days down to roughly 30 minutes of SQL.
- p50 latency, customer egress to our EU edge: 42 ms.
- RFP wins citing the per-shipment carbon line: 7 in the cycle after go-live.
- First CSRD-ready Scope 3 Cat 4 submission: Q1 2026, on time.
What they had before
The customer is a road-and-ocean 3PL with 1,200 trucks and three Mediterranean ocean lanes — Valencia-Genoa, Algeciras-Tangier, and Barcelona-Marseille — running on top of an Iberian road network out of hubs in Madrid, Lisbon, and Zaragoza. They handle roughly 12,000 shipments a month. Their sustainability lead had been producing a quarterly emissions report in Excel for eight years.
The workflow was sensible for 2017 and creaky for 2026. Shipment exports from Blue Yonder were dropped into a workbook every Monday morning. A lookup tab mapped truck class and lane to DEFRA 2019 conversion factors. The sustainability lead spent between two and five working days at the end of every quarter cleaning the data, chasing missing tonnages, and producing a single CO2e total split three ways — road, sea, total. The PDF reached the auditor between eight and twelve weeks after quarter-end.
Three things forced the conversation. CSRD assurance scope expanded to Scope 3 Category 4 for their fiscal 2026 reporting. Two of their largest shipper customers started asking for per-shipment carbon on quote responses. And their auditor flagged DEFRA 2019 as out-of-date for cross-border lanes that crossed into and out of the UK, which made GLEC the cleaner methodology base.
The pain we heard on the first call was specific. There was no per-shipment granularity for shipper quote requests. There was no way to answer "what is the carbon on this Valencia-Genoa booking?" inside the SLA of the quote response. And every quarter the data was already a season out of date before anyone looked at it.
What changed
We integrated the EcoFreight REST API into Blue Yonder via the customer's existing event bus. The shape is the one we recommend for any TMS-driven flow. On a "shipment booked" event, a thin middleware service builds the request payload, calls POST /api/v1/calculate, and writes the returned calculation_id and co2e_kg back onto the shipment record. Every quote response, BOL, and invoice that already templated off the shipment record picked up the carbon line without further template work.
The factor set switched cleanly to GLEC Framework v3.2 — current as of 2026, ISO 14083:2023-aligned, and the right base for cross-border lanes. WTW is the default scope; the response also returns the TTW and WTT split so the auditor and the customer's own ESG team can both have what they need without two API calls.
For their three Mediterranean ocean lanes we configured the request to use the container-ship factor segmented by TEU class, because two of their carriers run Post-Panamax-class vessels and one runs feeders. That single segmentation move shifted the per-tonne factor by about 14% on the Valencia-Genoa lane in their favour. On Iberian road we use the GLEC v3.2 articulated truck above 32 tonnes factor with the customer's actual load factor (78% from telematics) rather than the implicit assumption baked into their old DEFRA Excel.
The sustainability dashboard reads from the same column the middleware writes to. The quarterly report became a SQL aggregation that runs in about 30 minutes, almost all of it spent double-checking the cut-off date and signing the PDF.
Where the numbers landed
Measured after the first full quarter
- API p50 latency, customer egress to EU edge: 42 ms.
- p95 latency: 198 ms, dominated by first-seen lane distance cache misses; converged downward as the lane set saturated.
- p99 latency: 487 ms, almost all of it cold-start retries after our deploys.
- Error rate over the quarter: 0.09%, almost entirely bad lat/lon for two inland depot codes; fixed by the customer in week three.
- Reporting effort: 2-5 person-days quarterly down to ~30 minutes of SQL.
- Lag from booking to number on dashboard: 8-10 weeks down to under one second.
- RFP cycle wins citing the carbon line: 7 new shippers won across the Q1-Q2 2026 RFP cycle, against a typical baseline of 2-3.
- First CSRD-ready Scope 3 Category 4 submission: on time, signed by the assurance provider without methodology rework.
The seven RFP wins are the headline. In each case the buyer was a CSRD-bound EU shipper whose own ESG team was tightening Scope 3 reporting. Four of the seven award letters explicitly cited "per-shipment WTW emissions on the quote" as a differentiator versus the incumbent forwarder. We do not claim the carbon line alone won those bids — service levels and rate sheets still did most of the work — but for the first time the carbon line was not a reason to lose.
An honest gap
Full Excel retirement took two quarters of dual running. The new numbers were ~8% lower than the legacy Excel total in the first reconciliation, and the sustainability lead's first instinct was that the API was wrong. It was not — the gap traced to DEFRA-versus-GLEC factor differences (~5%), distance rounding in the Excel lookup (~2%), and a handful of cancelled bookings that lived in the export but not in the API stream (less than 1%). But proving that to the auditor took the full Q1 cycle, and we maintained the Excel through Q2 in parallel before the customer felt comfortable retiring it after Q3 sign-off.
We will not skip this step on the next migration either. The dashboard wins for new shipments; reconciliation against the old workflow takes time we cannot short-circuit.
"We stopped losing RFPs the day we could show a real CO2 number on every quote line. The Excel did not retire overnight — we ran both for two quarters before our auditor was comfortable — but I will not go back."
— Director of Operations, European 3PL (anonymised by request)
What we would do differently
Two things, on the next migration of this shape.
The first is reconciliation tooling. We did the Q1 reconciliation by hand in a Jupyter notebook, attributing the 8% gap to its four causes one row at a time. That work belongs in a product. We have it on the roadmap as a "diff this CSV of legacy totals against the API stream" endpoint; it was not ready in time for this go-live.
The second is load-factor onboarding. The customer's actual load factor was 78% from telematics; their old Excel implicitly assumed 65%. The right answer was to flow telematics into the request from day one. We did, eventually — but only after the first reconciliation surfaced the gap. On the next migration the load-factor source goes into the first integration sprint, not the second.
Named tooling and references
- Blue Yonder TMS — event bus integration via the customer's middleware layer.
- GLEC Framework v3.2 — Smart Freight Centre (2023).
- ISO 14083:2023 — methodology and data quality tier rules.
- CSRD — EU Corporate Sustainability Reporting Directive, Scope 3 Category 4.
- EcoFreight API — see the docs for the request schema and methodology for factor sourcing.
Want this kind of integration?
Email sales@ecofreight.co with your TMS, monthly shipment count, and the framework you need to satisfy. We will reply with a candid scope estimate — including the dual-running window we will recommend.