Codat vs Unified.to: which should you use for accounting integrations in 2026?

June 10, 2026

Codat and Unified.to are usually compared as competing unified APIs. On the evidence of Codat's own pages in August 2026, they are no longer the same kind of product. Codat's homepage sells advisory intelligence to commercial banks, its current products are use-case bundles for lending, bill pay, expenses and bank feeds, and its general-purpose Accounting API reference opens by telling new enquiries it is relevant only to existing clients.

That makes the decision simpler than a feature table suggests. Choose Codat if you are building a financial product for banks or lenders, or if you need bank feeds written into a customer's ledger, which Unified.to does not offer at all. Choose Unified.to if you are building B2B SaaS or AI products that read and write accounting data alongside other categories, and you want an integration layer rather than a packaged financial product.

All figures below were checked against both vendors' published documentation on 6 August 2026.

How do Codat and Unified.to compare?

What is Codat selling in 2026?

Advisory intelligence to commercial banks. That is Codat's own description, and the shift is documented on its own properties.

In June 2022, announcing its Series C, Codat described itself as the universal API for small business data. In May 2026 it launched what it calls an advisory intelligence solution purpose-built for modern commercial banking, introducing FX Insights, Spend Insights and Working Capital Insights sold to bank card and treasury teams, with BMO as launch partner. The homepage today leads with finding tomorrow's opportunities in today's data.

The site is now two tiers. Codat Insights leads, covering Spend Insights, Working Capital Insights, Commercial Card Sales and Treasury Sales. Codat Connect follows, covering Underwriting and Monitoring, Bill Pay, Expense Management and Bank Feeds. The integration business survives inside Codat Connect. It is not the headline.

What are the receipts?

Four facts, each checkable on Codat's own pages.

The Accounting API reference opens with a box headed New to Codat, stating that the reference is relevant only to existing clients and asking new enquiries to contact Codat so it can find the right product for them. Codat maintains a precise lifecycle vocabulary elsewhere, so this is not a deprecation notice. It is a statement that the general-purpose accounting API is not what a new customer buys.

The current products are use-case bundles rather than a general data layer: Bank Feeds, Lending, Expenses and Bill Pay, plus Platform and Files as utilities.

The integration estate is contracting. In October 2025 Codat announced the deprecation of 14 integrations for low or no usage, naming PayPal, Mollie, PrestaShop, Chargebee, Recurly and Maxio among them, across two waves ending January 2026. In March 2026 Sync for Payables v1 and Sync for Expenses v1 entered Maintenance, defined by Codat as no longer sold with no new features and no planned bug fixes, and Sync for Payroll entered Maintenance with no direct replacement. API access to those products ends 1 May 2027.

And codat.io has no integrations catalogue page at all. The entire marketing site is 24 pages, and every integration is documented only.

None of this means Codat is a worse company. It means the buyer moved, from a fintech product manager to a commercial banking line of business, and a SaaS team evaluating Codat because a comparison listicle put it on the shortlist is evaluating a product built for someone else.

What does Codat do well?

Bank feeds, and it is a genuine no-build. Codat writes bank transactions into six accounting platforms: QuickBooks Online in the US and Canada, Xero, Sage, Oracle NetSuite Premium, FreeAgent and Exact Online in the Netherlands. The gating is the kind engineering cannot close. QuickBooks Online bank feeds must be enabled by Intuit before going to production, with Codat making the request on the client's behalf. Xero requires the customer to become a Xero App Partner, complete a partner agreement and pass a technical certification, and Codat's own documentation warns it can take several months. Unified.to does not offer bank feeds and does not intend to. If bank feeds are your requirement, the comparison ends here.

A wider accounting object surface. Codat's Accounting API reference lists 26 endpoint groups against Unified.to's 20 accounting objects, including item receipts, items and payment methods, which Unified.to's accounting category does not model. Codat splits customers and suppliers into two objects where Unified.to has one Contact, and splits payments and bill payments where Unified.to has one Payment with an allocations array. Unified.to models balance sheet, trial balance, profit and loss, cash flow and vendor credit as distinct objects where Codat groups the financial statements under Reports. Object count measures how a schema is divided rather than what you can read, but Codat's accounting model is the wider of the two and any claim to the contrary will not survive checking.

Deletion detection on every platform it syncs. Because Codat diffs against a stored copy, it catches records deleted in the source software regardless of whether that platform supports it. Deleted records are retained and flagged rather than removed, and you exclude them with a query filter. Unified.to's delete events reach 11 of 105 accounting integrations, and Xero, NetSuite and Sage Intacct carry none.

Attachment writes. Codat uploads attachments on six data types with documented per-platform size limits: Xero 10 MB, QuickBooks Online and NetSuite 100 MB, Dynamics 365 Business Central 350 MB, FreeAgent 5 MB, and QuickBooks Desktop unsupported. Unified.to reads attachments more widely than it writes them, with writes on Bill, Creditmemo and Invoice across three integrations each.

Compliance depth. Codat holds SOC 2 Type II and ISO 27001:2022, with a 2025 certificate of registration, a 2026 penetration test, tested business continuity and 20 published policies on a public trust centre. Unified.to does not hold ISO 27001. If that is a hard procurement requirement, Codat clears the bar and Unified.to does not.

Two further things Codat has and Unified.to does not. Holding a copy means a customer's history survives a disconnection and can be queried without touching the source platform, which a routed read cannot offer and which is the honest counterpart to the cadence argument below. And Codat's Lending solution carries derived reports, including aged creditors, aged debtors, enhanced cash flow, credit model and data integrity reporting. Those are a different product category rather than a schema gap, and a lending buyer will ask for them.

Where does each platform hold your customers' financial data?

Codat holds a copy and serves reads from it. Unified.to does not hold one.

Each vendor states it plainly. Codat's dataset lifecycle documentation describes the processing stage as the data being stored into Codat's cache, after which it is available to be queried through Codat's API. Unified.to's accounting documentation states that requests are stateless and reach the accounting platform directly, with no caching.

The sharper fact is the cadence Codat recommends. Sync frequency is configured per data type and defaults to none until you set it. Codat's sync guidance offers four options and recommends weekly, describing it as keeping data reasonably fresh while reducing API calls. Daily is described as giving a close-to-live picture. Hourly is flagged as recommended for specific use cases only, with rate limits to consider, and it is excluded from Codat's free trial, so a developer evaluating Codat cannot test its fastest cadence without a contract.

That is the cadence argument, and Codat makes it about Codat. For a lending model running on weekly financial statements it is the right design. For a product whose UI shows open invoices that need to match the customer's ledger now, or a write that needs to be confirmed rather than pending, a weekly-by-default copy is a different class of problem.

What else follows from holding the copy?

Three consequences, none of which are about cadence.

Reads can fail in a way routed reads cannot. Codat documents eight sync error states including auth expiry, fetch, mapping and validation errors. When a sync fails, data lags until someone diagnoses and re-queues it, and a sync cannot be queued for a data type while one is already running. Codat returns HTTP 409 when data is requested before a sync completes.

Writes are asynchronous and Codat does not retain what you wrote. Write requests return Pending and resolve to Success, Failed or TimedOut over seconds to minutes. Codat's timeout documentation describes a Pending stage that precedes the operation moving upstream to the target software, and warns operations can stay Pending indefinitely on on-premise integrations like QuickBooks Desktop and Sage 50 UK. Codat does not cache written records, so you retrieve a record you just created by syncing again and caching the ID from the write webhook.

And the copy is a compliance object. Customer accounting data resting in a vendor's infrastructure is a sub-processor to scope, audit and delete. Where nothing is held, there is nothing to scope.

How do you find out when something changed?

Codat tells you when a sync finished. Unified.to tells you which record changed.

Codat's documented webhook event types cover company and connection lifecycle, rate limits, report generation, the outcome of your own writes, and sync completion. None of them is a record change. There is no invoice created, no invoice updated, no invoice deleted. You receive read.completed, then query Codat's cache and work out what moved.

Unified.to emits record-level created and updated events across the accounting catalogue: contact created on 49 integrations and updated on 47, invoice created on 43 and updated on 42, sales order created on 28, bill created on 22, account created on 21.

The reverse is true on deletions and it is worth stating plainly. Codat flags deleted records on every platform it syncs, because diffing a stored copy needs no support from the source. Unified.to's delete events are defined on 12 of 20 accounting objects and reach 11 of 105 integrations as of August 2026, and the three ledgers most enterprise deals turn on, Xero, NetSuite and Sage Intacct, carry none. If your product must know when a record disappears from the ledger, check that specific platform on either vendor before committing.

Which one covers more integrations?

Unified.to covers more in every category both vendors serve. 675 integrations across 32 categories against the 28 production integrations in Codat's documented catalogue.

Two of those are not really coverage gaps. Plaid and TrueLayer are bank-data aggregators Codat resells, and a buyer who wants Plaid can buy Plaid. Sage 50 UK and Sage 200 Standard are genuine gaps, both UK-market and one on-premise, and Zettle is a genuine gap that Codat notes is unsupported in the United States.

Codat's own published counts do not agree with each other. Its documentation says 30 or more platforms, its expense management page says more than 20 accounting platforms, and the Accounting API reference describes itself as covering 20 accounting integrations against a catalogue of 17. All are Codat's figures.

Can you tell which platforms support which fields?

On Unified.to, yes, before you build. The per-integration capability matrix covers all 105 accounting integrations and filters by data objects, readable fields, writable fields, webhooks and list parameters.

Codat publishes a write-support table by data type only, platform-agnostic, and per-platform integration reference pages that document caveats and unavailable fields rather than coverage. Per-platform write requirements are retrievable at runtime through its Get model endpoints. No per-platform, per-data-type grid was found anywhere on its documentation.

The practical consequence is that a question like whether NetSuite supports journal entry writes at a given field depth is answerable from Unified.to's documentation and answerable from Codat only by building against it or asking.

For depth rather than breadth, Unified.to documents 348 readable accounting fields across the catalogue, with QuickBooks at 257, Xero 226, NetSuite 203 and Sage Intacct 161.

What happens when you need data outside the unified model?

Both vendors have an answer, and they are different shapes: Codat's is a configuration step registered in advance, Unified.to's is a parameter on the request.

Codat has two mechanisms. Supplemental data extends standard data types with source properties it has not mapped, configured by registering a client object name, platform endpoint and property name against a specific integration and data type. Custom data types fetch objects outside the standard model, naming Xero Payroll and NetSuite Expense Reports as examples.

Both carry constraints Codat documents. Supplemental data supports reading and creating but, in Codat's own words, does not support updating. It is not available at record level and cannot reach line-level properties. Its contents are not validated or standardised. Custom data types are fetch only, with no create, update or delete, one data source per type, no nested objects, and no querying. Configuration changes trigger a full resync of the affected data types.

On Unified.to the equivalent mechanisms are arguments on the call:

await sdk.payment.createPaymentPayment({
  connectionId, paymentPayment: { }, fields: '', raw: '',
});

fields=raw returns the source object alongside the unified one on the same request, a raw object in the write payload carries integration-specific fields, the raw query parameter passes source query parameters, and the Passthrough API reaches any unmapped endpoint in either direction on the connection you already have. Codat's equivalent is a configuration call made in advance:

PUT /integrations/{platformKey}/datatypes/{datatype}/supplementalDataConfig

One is an argument to the request. The other is a provisioning step, per integration and per data type, followed by a resync.

Two differences hold up. Codat cannot update through either mechanism, and Codat's escape hatches are registered per integration and per data type where Unified.to's are per request.

What can each one write back?

Both write to the ledger, and Codat's current product is the narrower of the two: its Bill Pay solution pays one bill at a time, and it has no receivables line at all.

Codat's Bill Pay documentation states that the solution supports payments of single bills only, and separately that it supports payments where a single bill is paid in full. Multi-bill allocation and partial payments do exist in Codat's estate, on two routes: Sync for Payables v1, which Codat placed in Maintenance in May 2026 and describes as no longer sold, and the closed Accounting API. Both quotes are Codat's own.

Bill Pay v2 also has no get, list or delete for bill payments. Payments are write-only with no read-back, where v1 had all three.

There is no receivables product. Codat's solution line covers Payables, Expenses, Commerce, Payroll and Bank Feeds. Its own receivables guide names the Accounting API as the answer for writing invoices and customer records. Sync for Payables v2's data types include no Invoice, no Customer and no Payment.

On Unified.to, Invoice, Contact and Payment are ordinary objects on the same connection. Payment.allocations covers six document types in one object spanning receivables and payables, where Codat needs Payment and BillPayment as two objects. On the accounting side, Invoice.payments and Bill.payments read on five integrations: Moneybird, NetSuite, QuickBooks, QuickBooks Desktop and Xero. Note that Payment sits in the Payments category rather than Accounting, so a Payments-category connection is involved, and Sage Intacct and Dynamics 365 Business Central are not among the 40 Payments integrations.

How does each one model tracking dimensions?

Codat uses an untyped parent and child tree; Unified.to uses one object with a typed enum. Neither wins outright.

Codat's tracking category is a generic parent and child tree with no type discriminator, so class, department, location and project are not distinguishable on the category object itself. Tracking categories do not appear in Codat's write-support table, and per-platform behaviour varies where writes are possible: on Xero, Codat documents that a tracking category is writable only when it has a parent and no children, so it writes tracking options rather than the categories above them. Unified.to's Category carries a typed enum across eight kinds: class, department, location, project, task, custom, expense and income.

Codat is richer at the line. Its invoice line item tracking object carries category references, a customer reference, a first-class project reference and billed-to and rebilled-to flags. Unified.to has category IDs at header and line level and no project or billable concept in the accounting category.

Both are thin on coverage. Unified.to's category_ids is readable on between two and five integrations depending on the object. Codat does not publish per-platform coverage for tracking, so no comparison of reach is possible in either direction.

Does either model multiple legal entities?

Unified.to has a model for it and Codat does not. Codat's company information object carries 14 fields and none of them is a parent, subsidiary, hierarchy or consolidation reference. Its unit of account is one company per connected entity, and its NetSuite reference page states that writing data to subsidiary companies is not supported.

Unified.to's Organization object carries a type of company, subsidiary, division or location readable on 8 integrations, is_elimination on 7, parent_id on 2, fiscal_year_end_month on 12 and organization_code on 16. The coverage is thin and the model exists, which is the honest way to state it.

What does each one cost?

Codat publishes no pricing at all; both codat.io/pricing variants return 404 and no pricing URL appears in its sitemap. Unified.to publishes three tiers: Grow at $750 a month for 750,000 API calls, Pro at $1,500 for 2 million, and Scale at $3,000 for 6 million, with all 32 categories and unlimited customer connections on every plan.

Codat's billing unit is published in its own contract rather than on a pricing page. Its standard MSA defines unit fees as payable per active company per month, with an active company defined as one that has completed at least one data synchronisation that month, plus annual platform fees for access to the products, both set in an order form. Platform fees are annual with a CPI-linked uplift, and Codat's legal FAQ states it cannot agree to termination for convenience.

That is an enterprise contract shape rather than a developer-platform one, and it is consistent with everything else on this page. Codat's free trial carries three documented limits: a 50-company cap, no hourly sync, and expiry after 365 days.

How do the two compare on security and compliance?

Codat is strong here and it would be a mistake to suggest otherwise. Its public trust centre lists SOC 2 Type II with a dated audit window, ISO 27001:2022 with a 2025 certificate of registration, a 2026 penetration test, tested business continuity and disaster recovery, cyber insurance and 20 named policies. AES-256 at rest, TLS 1.2 in transit, annual penetration testing and a managed bug bounty.

Codat also states compliance with GDPR and the Australian Privacy Principles, and states that PCI DSS is out of scope because it does not process card data. Unified.to holds SOC 2 Type II, GDPR, CCPA/CPRA and PIPEDA, with HIPAA BAAs available on Scale. It does not hold ISO 27001.

The difference that matters for procurement is residency rather than certification. Codat's subprocessor list names Microsoft Azure as its single critical third party, processing and storing data in UK South, UK West and US East. Unified.to operates in named US, EU and AU regions. A buyer with an EU or APAC data-residency requirement is not served by three UK and US regions, and that is a residency fact rather than a compliance failing, since the UK holds adequacy.

When should you choose Codat?

Start here: who is your product for? Codat sells to commercial banks, lenders and fintechs building financial products. If you are underwriting SMB credit, monitoring borrowers, reconciling card spend into a ledger or building treasury advisory, Codat's packaged Lending and Insights products, its derived reports and its go-to-market are built for you, and buying a general integration API instead means building those products yourself. If you are a SaaS or AI product that needs accounting data among other things, keep reading, because two narrower requirements can still settle it.

Two requirements end the comparison regardless of what you are building:

Bank feeds. Six write targets on Codat, none on Unified.to, and the gating is a partnership process rather than an engineering one.

ISO 27001. Codat holds ISO 27001:2022 with a current certificate of registration. Unified.to does not hold it. If your buyer's security review treats that as mandatory, no other row in this comparison matters.

And one weighted reason:

Your workload is analytical and historical rather than live. A weekly or daily copy that survives a customer disconnecting, queryable without touching the source platform, is what a cache is for. If you are reconstructing statements at a point in time rather than showing a customer their current balance, the architecture is a fit rather than a compromise.

When should you choose Unified.to?

Start here: does your product write invoices or customer records? Codat's current solution line covers payables, expenses, commerce, payroll and bank feeds. There is no receivables product, and Codat's own receivables guide routes that work to the Accounting API, the one closed to new customers. If writing an invoice is on your roadmap, this is settled before any other comparison.

Otherwise, six reasons:

You need the write confirmed by the ledger, not accepted by a vendor. Codat's write requests return Pending and resolve over seconds to minutes. Its own documentation describes a Pending stage that precedes the operation moving upstream to the target software, and warns that operations can stay Pending indefinitely on on-premise integrations like QuickBooks Desktop and Sage 50. Bill Pay v2 has no read-back for payments at all. On Unified.to the write executes against the source API and the ledger returns its own answer, so your retry logic operates on confirmed state rather than on a job status.

Nothing is held. Your customers' financial records never rest in a third party's infrastructure. If a vendor holding a copy is breached, the records exposed are your customers' books. Holding nothing removes a sub-processor from your compliance chain, removes the retention and deletion commitments a reviewer inherits, and removes any data migration if you later switch vendors. Codat holds a copy by design, which is what buys it deletion detection and historical depth, and it is also what a security review has to scope.

You need more than accounting, or more than 17 accounting platforms. 105 accounting integrations against 17, 78 commerce against 9, and 40 payments integrations against a vendor with no payments category. Beyond that, CRM, HRIS, ATS, ticketing and messaging sit on the same authorization model, which Codat's catalogue does not cover at all.

Your UI has to match the ledger, and you need to know what changed. Reads route to the source on each request, so there is no sync cadence to configure and no sync to fail, where Codat's recommended default is weekly. And record-level created and updated events arrive across the accounting catalogue, against a webhook set that covers lifecycle and sync completion and no record changes at all. Detection runs on a one-minute minimum, and a check that finds nothing is not billed, so what you set the interval to is not governed by what each check costs.

Nothing you need is out of reach, and you reach it on the request. Three questions decide this rather than one: can you read custom fields, can you get the original source object, and can you call the endpoints nobody has unified. On Unified.to all three are parameters on the call, and Passthrough works in both directions. Codat answers the first two by registering a configuration against a specific integration and data type and waiting for a resync, and neither of its mechanisms can update: supplemental data is read and create only, custom data types are read only.

The pricing is published and it tracks usage. Three tiers from $750 a month, billed on API calls, with connections and customers unlimited on every plan. Codat publishes no prices, and its own contract defines the unit as a fee per active company per month plus an annual platform fee, set in an order form. That bills you for how many customers have connected rather than how much you use. Per-connection pricing is pricing electricity by the bulb: you do not pay more because you installed more fixtures, you pay for what you draw. Codat's legal FAQ also states it cannot agree to termination for convenience.

Is there a case where either one works?

Probably not, and it is worth saying so rather than manufacturing a middle.

The overlap case would be a product that needs accounting and nothing else, on a handful of ledgers, reading rather than writing, where weekly data is acceptable. That describes a real segment. But a new customer cannot buy Codat's general-purpose Accounting API today, so that buyer is routed to Lending, Bill Pay or Expenses, which are packaged products for specific financial use cases rather than an integration layer to build on.

Which leaves the decision where the opening put it. If you are building a financial product for banks and lenders, or you need bank feeds, or ISO 27001 is mandatory, Codat is the answer. Everywhere else the two products are solving different problems, and the comparison listicles that still group them have not caught up.

Frequently asked questions

Which has deeper accounting coverage?

It depends what you mean by deeper. Codat's accounting object model is wider, at 26 endpoint groups against Unified.to's 20, and it is more opinionated in service of lending and reconciliation. Unified.to covers 105 accounting integrations against Codat's 17 and publishes a per-integration, per-field capability matrix that Codat has no equivalent to.

Can I still buy Codat's general-purpose Accounting API?

Its reference page states that it is relevant only to existing clients and directs new enquiries to a Codat contact. Codat has not applied the word deprecated to it, and it maintains a separate four-state lifecycle vocabulary that it has not used here. The accurate statement is Codat's own.

Can I use Codat and Unified.to together?

Some teams do, using Codat for bank feeds or lending-specific flows and a broader integration layer for everything else. Bank feeds in particular have no equivalent, so a product that needs them and also needs categories beyond accounting has a genuine two-vendor case. It is two contracts and two sets of credentials, so price it before committing.

Related reading: Architecture trade-offs: routed versus cached unified APIs · Merge vs Unified.to · Kombo vs Unified.to · Truto vs Unified.to · Usage-based versus per-connection pricing

Sources: codat.io, docs.codat.io, legal.codat.io, trust.codat.io, Codat's published OpenAPI specifications and generated SDK source; Unified.to documentation, pricing page and first-party capability exports. All checked 6 August 2026.