Scaling financial data integrations: what we learned moving from Codat to Nango

How integration architecture decisions evolve as a carbon accounting platform matures, and what SaaS founders should consider when choosing between unified APIs and orchestration layers.

Why integrations matter in carbon accounting

Carbon accounting is, fundamentally, a data problem. The quality of an emissions report depends on the quality of the financial data that feeds it.

At EcoHedge, financial data ingestion is not a peripheral feature. It is the foundation of everything we do. When a customer connects their accounting platform, that connection underpins Scope 3 spend-based estimates, emissions categorisation, audit trails, and regulatory reporting. The accuracy of a carbon report is only as reliable as the data pipeline that produced it.

This is why our integration architecture decisions carry weight that extends well beyond engineering convenience. They directly affect the defensibility of every report we produce.

Why we chose Codat initially

When launching an early-stage SaaS product, speed matters. Codat's Lending API provided structured access to accounting data and allowed us to ship our first integrations without building complex OAuth and sync infrastructure from scratch.

The decision was rational and well-considered:

• Lending API maturity. Codat's Lending product offered a well-structured interface for accessing financial statements, balance sheets, and transaction data across multiple platforms.
• Clean accounting connectors. Xero, QuickBooks, FreeAgent, and Sage were all available through a single integration point.
• Speed to market. Rather than building OAuth flows, token management, and data normalisation from scratch, we focused our engineering effort on the emissions engine itself.
• Standardised data schema. Financial data from different platforms arrived in a consistent format, reducing the categorisation complexity for our carbon accounting software.

For that phase of growth, it was the right decision. Authority comes from nuance, and nuance means acknowledging when something served you well.

What changed as we scaled

As EcoHedge matured, our integration layer became part of our core infrastructure rather than an acceleration layer. Several factors drove this shift:

• Cost structure evolution. Platform access fees combined with per-connection charges created a cost profile that became less predictable as customer volumes increased. Forecasting infrastructure spend became harder.
• Predictability at scale. With growing transaction volumes, we needed a pricing model where costs scaled linearly and visibly alongside usage.
• Need for orchestration control. Carbon accounting requires precise mapping of financial line items to emission factors. Our categorisation engine needed deeper control over how raw data was fetched, transformed, and stored.
• Product roadmap evolution. As we developed the EcoHedge API, integration reliability became a product feature rather than an internal dependency.
• Internal QA and rules engine maturity. Our data validation, categorisation rules, and audit trail systems had matured to the point where the normalisation layer was adding a dependency we no longer needed.
• Token lifecycle transparency. Managing OAuth tokens, handling reconnections, and monitoring data freshness required more visibility than an abstracted layer provided.

This was not a sudden decision. It was a gradual recognition that the integration layer had moved from utility to strategic component.

Why Nango fit the next phase

Nango takes a fundamentally different approach to accounting API integrations. Rather than abstracting data into a unified schema, it provides primitives for connection orchestration, authentication management, and API proxying.

In practice, this means:

• Connection orchestration. Nango manages the OAuth authorisation flow and automatic token refresh across accounting platforms. The complexity of token lifecycle management is handled without abstracting the underlying data.
• Pricing simplicity. Nango publishes transparent, usage-based pricing tiers on its website. For our usage patterns, the predictability of a published model became important as transaction volumes scaled.
• Engineering control. Data transformation, categorisation logic, and sync scheduling all live within our own architecture. We query Xero and QuickBooks APIs directly through Nango's proxy layer.
• Long-term extensibility. Adding new data sources, custom sync logic, or specialised audit behaviours does not require waiting for a third-party product roadmap.

Nango is not "better" than Codat in any absolute sense. It was better for our phase. That distinction matters.

Structured comparison: Codat vs Nango

The following comparison reflects our experience and is not intended as a universal recommendation. Your mileage will vary depending on product maturity, team size, and integration complexity.

How the architecture changed

The trade-offs

Balanced analysis is the foundation of credibility. Moving from a unified API to an orchestration layer is not a free upgrade. It involves real trade-offs that any engineering team should evaluate honestly.

• Codat advantage: faster initial enrichment. A unified schema means less engineering effort to get structured data flowing. If you are pre-product-market fit and need accounting data quickly, this is genuinely valuable.
• Nango advantage: deeper infrastructure ownership. Once your product matures and integrations become strategic, the ability to control data transformation, sync logic, and token management directly pays dividends in reliability and auditability.
• Migration cost. Moving between integration providers is not trivial. It requires re-implementing data fetching logic, mapping fields to your internal schema, handling token migration for existing customers, and running parallel systems during the transition period.
• Ongoing maintenance. With Nango, the normalisation and transformation logic lives in your codebase. That means more code to maintain, more edge cases to handle, and more engineering time allocated to integration infrastructure.

We accepted these trade-offs because the long-term benefits of architectural control outweighed the short-term migration cost. That calculus will differ for every team.

Lessons for SaaS founders

This section is not specific to carbon accounting. It applies to any SaaS product that relies on financial data integrations as part of its core value proposition.

When to choose a platform API

Unified APIs like Codat are the right choice when speed to market is more important than architectural control. If your team is small, your product is still finding its shape, and you need accounting data flowing within weeks rather than months, a managed platform removes significant complexity.

The trade-off is dependency. You inherit someone else's data schema, sync schedule, and pricing model. For early-stage products, that trade-off is usually worth making.

When to choose an orchestration layer

Orchestration layers like Nango become attractive when your integration layer transitions from a utility to a strategic component. Signals that you may be reaching this point:

• Your categorisation or transformation logic has outgrown the normalised schema.
• You need granular control over sync frequency and retry behaviour.
• Your pricing model is being affected by per-connection fees.
• Audit and compliance requirements demand full data provenance.
• You are building an API product that depends on integration reliability.

Cost modelling advice

Before committing to any integration provider, model your costs across three horizons: current state, 3x customer growth, and 10x customer growth. Pay attention to how per-connection fees compound. A model that is cost-effective at 50 connections may become a significant line item at 500.

Integration stack maturity stages

In our experience, most SaaS products move through three stages with their integration architecture:

• Stage 1: acceleration. Use a managed platform. Ship fast. Learn what data you actually need.
• Stage 2: evaluation. You start hitting the edges of the abstraction. Custom logic builds up around the normalised data. Costs become less predictable.
• Stage 3: ownership. The integration layer becomes a product feature. You invest in infrastructure that gives you direct control and long-term predictability.

Not every product reaches Stage 3. Many are well-served by a unified API indefinitely. The key is to recognise which stage you are in and make decisions accordingly.

What this means for EcoHedge customers

The transition delivers tangible improvements for every customer using EcoHedge's accounting integrations:

• More consistent data syncing. Direct control over API calls means fewer sync failures and faster recovery when issues occur.
• Improved reconnection flows. Token lifecycle management is now transparent, enabling proactive alerts when re-authorisation is needed.
• Greater visibility over data freshness. Customers and internal systems can see exactly when data was last synced and its current status.
• Stronger audit trail integrity. Every data point flowing into an emissions report has clear provenance from source to calculation.
• Long-term pricing stability. Predictable infrastructure costs translate to stable pricing for customers.

In carbon accounting software, integration reliability is not a convenience feature. It underpins emissions accuracy and regulatory reporting confidence.

Infrastructure is part of product quality

Most customers will never see the integration layer. But they benefit from its stability every day.

As reporting standards tighten and sustainability data scrutiny increases, owning critical components of our infrastructure allows us to build with greater precision and long-term resilience.

This transition was not about leaving one vendor for another. It was about recognising the stage our product had reached and making the infrastructure decisions that support the next phase of growth.