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

Codat now sells advisory intelligence to commercial banks, with its integration products packaged underneath; Unified.to is built for B2B SaaS and AI products. As of 8 October 2026, Codat calls itself "an advisory intelligence solution purpose-built for modern commercial banking", sells packaged bank-feed, bill-pay, expense and lending products, and says its general-purpose Accounting API reference is "relevant only to our existing clients"; Unified.to is a unified API across 36 categories, accounting included, that reads the source ledger on every call and stores no customer records. Choose Codat if you are building for banks or lenders, or need to write bank transactions into a customer's ledger; choose Unified.to if you are building B2B SaaS or AI products that read and write accounting data, alone or beside other categories.

How do Codat and Unified.to compare at a glance?

Codat and Unified.to differ most on who they sell to, how current the data is and how they price; both have SOC 2 Type II reports and both embed an authorization flow in your app. Codat figures come from Codat's own sites, docs, legal pages and published API specifications, and Unified.to figures from unified.to and its docs, all read on 8 October 2026.

Codat and Unified.to at a glance (checked 8 October 2026)

What is Codat selling in 2026?

Codat sells advisory intelligence to commercial banks, with its integration products packaged underneath. As of 8 October 2026, Codat's page for AI assistants says its "primary market is large commercial banks (top 100 U.S.)" and lists "Not a universal API" among its boundaries.

• Repositioning. On 5 May 2026 Codat announced "a strategic repositioning and a new advisory intelligence platform purpose-built for commercial and business banks", with FX Insights, Spend Insights and Working Capital Insights, and names BMO "among the first banks to collaborate". Its homepage leads with "Find tomorrow's opportunities in today's data".
• 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.
• Accounting API reference withdrawn. Codat removed its public Accounting API reference on 16 September 2026. The API specification on GitHub still opens with a box headed "New to Codat?": "Our Accounting API reference is relevant only to our existing clients. Please reach out to your Codat contact so that we can find the right product for you." The same box opens the Commerce, Banking, Assess and Files specifications. Codat applies none of its four lifecycle labels (Active, Maintenance, Deprecated, Retired) to the Accounting API.
• Products for technology teams. Bank Feeds, Bill Pay, Expenses and Lending, plus Platform and Files as utilities; Spend Insights is sold to banks.
• Fewer integrations and products. In October 2025 Codat announced "Codat is deprecating integrations with low or no usage": 14 integrations, including PayPal, Mollie, PrestaShop, Chargebee, Recurly and Maxio, removed in two waves ending January 2026. In a notice published 30 March 2026 and effective 1 May 2026, Sync for Payables v1 and Sync for Expenses v1 entered Maintenance ("No longer sold"), Sync for Payroll entered Maintenance with "no direct replacement", and API access to those products ends 1 May 2027.

What does Codat do well?

Codat does bank feeds, lending reports and audited security well, and its stored copy keeps a customer's history after they disconnect. As of 8 October 2026:

• Bank feeds into six ledgers. Codat writes bank transactions into QuickBooks Online (US and Canada), Xero, Sage, Oracle NetSuite Premium, FreeAgent and Exact Online (Netherlands). The gating is a partner process: "QuickBooks Online bank feeds must be enabled by Intuit before the solution can go into production", with Codat making the request, and Codat warns that "It can take several months to become a Xero App Partner" (Xero App Partner Program). As of 20 October 2026, Unified.to reads bank accounts and bank transactions from ledgers such as Xero and NetSuite, and account data from Plaid, Stripe and Brex, but writes no bank feeds, so writing transactions into a ledger's bank feed is Codat's win.
• Names and payments inline on accounting records. Codat's Accounting API specification, which Codat marks for existing clients only, returns display names on references (customerRef.companyName, accountRef.name) and embeds a payment summary in each invoice's payment allocations, so one read carries what Unified.to returns as IDs. It also has payment-method and transfer objects, and keeps customers and suppliers, and payments and bill payments, as separate objects where Unified.to has one Contact and one Payment with an allocations array. Bill Pay, Codat's current payables product, covers bills, bill payments, suppliers and bank accounts.
• History after a disconnection. "You can access any data that was already read or written using this data connection" (connections), queryable without touching the source platform.
• Lending reports. Codat's Lending product carries aged creditors, aged debtors, a credit model (a premium feature) and data integrity reports; enhanced cash flow was deprecated from the Assess endpoints on 10 July 2026.
• Attachment writes. Codat uploads attachments on six accounting data types: bills, bill credit notes, direct costs, direct incomes, invoices and transfers. Its size limits differ by page: Xero is 4 MB in the accounting schema and 10 MB on the Expenses receipts page.
• Audited security. SOC 2 Type II (report covering 1 July 2025 to 30 June 2026), ISO 27001:2022 (2026 certificate of registration), a 2026 penetration test, 2026 business continuity test results and 20 policies listed on its trust centre.
• Uptime credits and per-company rate limits. Rate limits of "1,000 x (1 + number of ACCs)" requests a day (rate limits), and uptime service credits in its standard terms, from 10% of the platform fee below 99% (Schedule 1).

Where does each platform hold your customers' financial data?

Codat holds a copy of your customers' accounting data and serves reads from it; Unified.to reads the source on every call and holds no copy.

Codat's dataset lifecycle documentation describes the processing stage in one line: "The data is being stored into Codat's cache." Unified.to's accounting requests are stateless and reach the accounting platform directly, with no caching. If you want a copy, Unified.to's Database Sync, on Grow, Pro and Scale, writes records for objects with native or virtual webhooks into your own MongoDB, MySQL, Postgres, MSSQL, MariaDB, Supabase or Snowflake database rather than a vendor's.

Codat's sync frequency is set per data type and defaults to none. Its sync guidance says "The recommended sync frequency is weekly", describes daily as a close-to-live picture and recommends hourly "for specific use cases only"; its data type settings list hourly as a "premium feature", and its error reference says an hourly schedule is "not included in the Free trial". For a lending model running on weekly financial statements that is the right design. A product whose UI shows open invoices that must match the customer's ledger now would show them as of Codat's last sync.

What else follows from holding the copy?

Holding the copy adds three concerns on Codat: sync errors, asynchronous writes and a stored copy to scope in a security review.

• Sync errors. Codat documents seven error states (FetchError, MapError, ValidationError, ProcessingError, InternalError, PermissionsError, AuthError), plus NotSupported. A sync can't be queued for a data type while one is already running, and Codat returns HTTP 409 when data is requested before a sync completes. Codat also says: "You should refresh at least one data type monthly to ensure your connection token does not expire."
• Asynchronous writes. "Write requests are asynchronous operations and will take between a few seconds to a couple of minutes to complete" (Codat). They resolve from Pending to Success, Failed or TimedOut, and Codat warns that write operations can stay in a Pending state indefinitely on on-premise integrations such as QuickBooks Desktop and Sage 50. "Codat does not store written records in its cache", so you read back a record you created by syncing again, for which Codat recommends hourly sync.
• A stored copy to scope. Customer accounting data in a vendor's infrastructure is a copy to scope, audit and delete. Codat offers enterprise clients "dedicated databases that can facilitate customer-specific encryption keys", and deletes the key within 5 working days of a request or termination; it publishes no retention period for cached data during the contract.

How do you find out when something changed?

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

As of 8 October 2026, Codat's webhook event types list 24 events covering company and connection lifecycle, rate limits, report generation, the outcome of your own writes and sync completion; none fires when a source record changes. You receive read.completed ("Indicates that the read of data types for a solution has completed."), then fetch changes from Codat's cache by modified date.

Unified.to sends created and updated events on accounting objects such as contacts, invoices, bills, sales orders and accounts, through native webhooks or virtual webhooks that detect changes and deliver the changed records, at a 1-minute minimum on paid plans and 60 minutes on the free trial; support varies by integration.

On deletions, Codat is ahead: because it diffs a stored copy, it flags records deleted in the source on every accounting integration ("For our accounting source data types, Codat stores records deleted by a company..."), as a flag to query rather than an event. Unified.to detects deletions by polling on ten integrations and passes native delete events where the source sends them. If your product must know when a record leaves the ledger, check that platform on either vendor; on Unified.to, that is the integration's Feature Support tab.

Which one covers more integrations?

Codat covers 28 platforms in three categories plus six bank-feed targets; Unified.to covers more accounting and commerce platforms, with 1745 integrations across 36 categories, and Codat has announced no new integration since December 2025 (as of 8 October 2026).

Coverage: Codat (its docs catalogue, 8 October 2026) and Unified.to

As of 8 October 2026, Unified.to covers the platforms in Codat's catalogue except Sage 50 Accounts UK and TrueLayer, including Plaid, Zettle, Clover and Sage 200 Standard & Professional. TrueLayer is a bank-data aggregator Codat connects to as a banking source; a buyer who needs it can contract with TrueLayer directly. Sage 50 Accounts UK is the real gap: an on-premise UK and Ireland ledger, which Codat sells with a desktop add-on. Codat also has a dedicated banking model (accounts, balances, transactions and transaction categories) on Plaid and TrueLayer, with a banking-only passthrough; Unified.to reads bank-feed accounts and transactions in its Accounting category. On commerce, Codat's specification has no write operations, while Unified.to writes items, variants, inventory and collections; support varies by integration.

Can you tell which platforms support which fields?

Unified.to publishes field-level support for each accounting integration before you build; Codat publishes write support by data type only. Unified.to's per-integration capability matrix filters by data objects, readable fields, writable fields, webhooks and list parameters. The model is also wider: Unified.to's invoice has 40 top-level and 25 line-item fields, a 10-value status enum and a typed fee enum on each line, against 26, 14 and six statuses in Codat's Accounting API specification (our count, 8 October 2026); support varies by integration.

Codat's write-support table has no integration column, and its per-platform reference pages document caveats and unavailable fields rather than coverage. Per-platform write requirements come from its Get model endpoints at runtime because, in Codat's words, "Required data may vary by integration." It does publish a supplemental-data grid for Xero, QuickBooks Online and QuickBooks Desktop.

The practical consequence: whether NetSuite supports journal entry writes at a given field depth is answerable from Unified.to's documentation, and from Codat only by calling its Get model endpoint on a live connection, or asking.

What happens when you need data outside the unified model?

Codat handles unmapped data with supplemental data and custom data types, registered in advance per integration and data type; Unified.to passes raw fields and unmapped endpoints as arguments on each request.

Codat's supplemental data extends standard data types with source properties Codat 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 (as of 8 October 2026):

• Updates. Codat's supplemental-data overview says "Codat does not support updating data using supplemental data"; its Xero page says the opposite ("when fetching, creating, or updating records").
• Record level only. "Supplemental data is currently available only at the record level and cannot be used to interact with line-level properties." Its contents are not validated or standardized, and a configuration change makes the next sync of that data type a full sync.
• Custom data types. Codat labels them an advanced feature; they "only support fetch operations", with one data source per type, no nested objects and no querying.

On Unified.to, they are parameters on the SDK 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. Custom-field lookup runs through the Metadata API on 50 platforms (as of October 2026), including QuickBooks accounting objects; writes happen in the normalized model. Codat's supplemental data is configured with this call:

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

Codat has no raw-payload field and no passthrough outside a banking-only one to Plaid and TrueLayer (as of 8 October 2026).

What can each one write back?

Codat and Unified.to both write to the ledger; Codat's current payables product, Bill Pay, pays single bills with no payment read-back, and Codat has no receivables product.

Codat's Bill Pay documentation says it "supports payments of single bills only"; to record a partial payment, Codat says to "use the same endpoint and adjust the values to reflect the amount of the partial payment." Bill Pay's overview mentions "bulk payments", but the guide to paying several bills with one payment is on Sync for Payables v1, in Maintenance since 1 May 2026 (announced 30 March 2026). Bill Pay creates bill payments and has no get, list or delete for them.

Codat's solution APIs are Bank Feeds, Bill Pay, Expenses and Lending (as of 8 October 2026). Bill Pay's data types include no invoice, customer or payment objects, and invoice writes exist only on the Accounting API described above. Lending reads invoices and customers, and the Expenses specification (labelled prealpha) creates and updates customers.

On Unified.to, Invoice and Contact are Accounting-category objects, and Payment sits in the Payments category, so recording a payment needs the Payments category enabled on the connection. Payment.allocations spans receivables and payables in one object, where Codat uses Payment and BillPayment, and Invoice.payments and Bill.payments link payments to documents; support varies by integration.

How does each one model tracking dimensions?

Codat models tracking categories as an untyped parent and child tree; Unified.to's Category object carries a typed enum of five kinds: class, department, location, project and task.

Codat's tracking category has 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 (Codat's Xero FAQ, 8 October 2026).

Both carry tracking at the line. Codat's invoice line item tracking object carries category references, a customer reference, a project reference and billed-to and rebilled-to flags; Unified.to's invoice and bill line items carry category_ids, contact_id, project_id and is_billable ("True when the line is rebillable to a customer").

Both are thin on published coverage. On Unified.to, category_ids support varies by integration and object (see the capability matrix); Codat does not publish per-platform coverage for tracking.

Does either model multiple legal entities?

Codat and Unified.to both model multiple legal entities, in different places: Codat links separate companies to each other, and Unified.to carries the hierarchy inside its accounting Organization object. Codat creates one company per entity, with parent and subsidiary references on the company object in its Platform API, and NetSuite OneWorld support ("Does our NetSuite integration support OneWorld? Yes.").

Codat's accounting company-information object carries no hierarchy field, and on NetSuite "only journal lines associated with the connected subsidiary are read"; suppliers can't be written to other subsidiaries (as of 8 October 2026). On Unified.to, the Organization object has a type (company, subsidiary, division or location), parent_id, is_elimination, fiscal_year_end_month and organization_code; support varies by integration.

How do Codat and Unified.to support AI agents and MCP?

Unified MCP is a hosted MCP server that lets agents read and write customer data across every Unified.to category; Codat's MCP connects Codat data to a bank's own AI tool and publishes nothing a developer can connect to.

Codat (as of 8 October 2026). Codat's Advisory Intelligence Platform "connects to a bank's approved AI tool through an open standard called an MCP", is "custom-engineered to each bank", and "Access is provisioned by the bank"; Codat's data is read-only there. Codat publishes no endpoint, transport, authentication method or tool list, and no developer MCP server, agent SDK or skills.

Unified MCP, documented for developers to connect to directly

• Connection-scoped URLs. Unified MCP generates a URL with a signed token good for one connection and nothing else, so the workspace API key stays on your side. hide_sensitive strips names, emails and phone numbers from results before they reach the model.
• Transport. Unified MCP is Streamable HTTP only, with one host per region (US, EU, AU), and supports the stateless core of the 2026-07-28 MCP revision in production; a credential works only on its own region's host.
• Tools. Unified MCP serves 22,566 tools, counting normalized tools and each vendor's own endpoints. A connection's tool list depends on the integration's feature support and the permissions you grant: one HubSpot connection carried 69 tools, 30 of them CRM, on 12 October 2026. Many models cap the number of tools they accept (Groq 10, most OpenAI models 20, Cohere about 50), so permissions and tools narrow the list and defer_tools marks tools for deferred loading.
• Writes. Agents write in the normalized model, so one create call adds an invoice in whichever ledger the connection uses; support varies by integration.
• Enterprise-managed authentication. Enabled per workspace on request: your identity provider issues an ID-JAG for the end user, exchanged at POST /oauth/token for an ema_ bearer token whose scopes, such as crm.read, filter the tools offered.

Building the integration with coding agents. A coding agent can build the accounting integration itself from Unified.to's Agent Skills, which give each How-To use case, accounting among them, its own SKILL.md. In Claude Code, one plugin installs every skill together with the Core MCP server; Codex, Cursor, GitHub Copilot and Windsurf take the skills with npx skills add https://docs.unified.to. Separate OAuth app-registration skills walk the agent through each vendor's developer portal.

How do Codat and Unified.to compare on security and compliance?

Codat and Unified.to both have SOC 2 Type II reports and state GDPR compliance; Codat also holds ISO 27001:2022, and Unified.to states CCPA/CPRA, PIPEDA and HIPAA compliance, with a BAA on Scale.

Security and compliance (checked 8 October 2026)

How do Codat and Unified.to price?

Codat publishes no prices; Unified.to publishes three plans billed by API call, with unlimited connections on every plan.

Codat (as of 8 October 2026)

• Order form. Prices are set in an order form.
• Billing unit. Codat's master services agreement (v3) defines unit fees as "the fee payable by the Client per active Company, per month", an active company being one that "has completed at least one data synchronisation in a given month", plus annual platform fees. Its legal FAQ uses a different test: data "pulled or pushed" in "the past 30 days".
• Contract terms. Contracts auto-renew unless the order form says otherwise, and the FAQ says "we are not able to agree to termination for convenience."
• Free account. Capped at 50 companies, with no hourly sync, and it expires after 365 days; Codat doesn't say whether new free accounts are still offered. Unified.to's 30-day trial reads the ledger on every call, where Codat's free account serves reads from its cache.

Unified.to (as of 8 October 2026, pricing)

• Grow: from $750 a month for 750,000 API calls; overage $1.00 per 1,000.
• Pro: from $1,500 a month for 2,000,000 API calls; overage $0.75 per 1,000. Adds SAML SSO, your own secrets manager, IP restriction, an authorization CNAME (US and EU regions), and log shipping to Datadog, Grafana and ClickHouse.
• Scale: from $3,000 a month for 6,000,000 API calls; overage $0.50 per 1,000. Adds a HIPAA BAA, 365-day logs and Multi-Region Sync.
• Grow, Pro and Scale include all 36 categories; Grow and Pro start with a 30-day free trial; Enterprise is custom.

How the billing units differ. Codat bills an annual platform fee plus a unit fee for each company that synced that month; Unified.to bills by API call, with connections unlimited. For how the two models behave as you grow, see usage-based vs. per-connection pricing.

Which should you choose?

Choose Codat when your buyer is a bank or lender, or you need to write bank transactions into the ledger; choose Unified.to when you write invoices, need current data, or need categories beyond accounting.

Frequently asked questions

What happens to my customers' connections if I leave Codat? Codat publishes no token export (it documents token migration only into Codat), its legal FAQ rules out termination for convenience, and at termination you have five business days to export company data before Codat deletes it (as of 8 October 2026), so plan to re-authorize customers. There is no Unified.to guide specific to Codat; the migration overview maps authorization, API calls, pagination, webhooks and passthrough. Only tokens issued to an OAuth app you own keep refreshing after you switch; on Unified.to, the API returns each connection's tokens if you later leave.

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 and Codat's published OpenAPI specifications on GitHub; Unified.to documentation and pricing page. Codat pages checked 8 October 2026.

Start your 30-day free trial of Unified.to or talk to our team to see how the architecture fits your product.

Written by Mallory Greene.

About the author: Mallory Greene is Head of Marketing at Unified.to_. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto._