Best unified API for accounting integrations in 2026

June 10, 2026

Unified.to's Accounting API covers 231 integrations, from ledgers and ERPs to the commerce, payments and spend platforms where the transactions originate, with readable and writable fields documented per integration in a published capability matrix. Every read and write routes to the source ledger at request time, so a write is confirmed by the ledger's own validation rather than accepted into a queue, and no customer financial data rests in the integration layer.

The alternatives sort by what you are building rather than by feature count. Codat is a financial data platform for banks and lenders. Rutter fits commerce-plus-accounting fintech. Merge is the multi-category default when accounting sits beside HRIS or CRM. Apideck and Truto are the other vendors that route requests by default rather than caching them. Four things decide it in practice: whether you need bank feeds, what happens to a write and when the ledger finds out, what you need beyond accounting, and what the bill does as you grow.

Why is writing to a ledger different from writing to any other system?

Because an accounting system is the system of record for someone's money, and the failure modes are specific.

A duplicate write into a CRM creates a redundant contact. A duplicate write into QuickBooks double-counts revenue, and reconciliation breaks quietly, weeks later. Four failure modes come up in every finance team's review of an integration.

Duplicates and idempotency. A timeout, a retry, a replayed job, and the same invoice posts twice.

Period-close locks. Accountants lock closed periods. An integration that posts into a locked period either fails mid-run or succeeds and reopens an audited month.

Drift between your write and the ledger. Where a write executes against the source API, the ledger returns its own confirmation: the bill exists in the books, or you have the ledger's error. Where an intermediate store sits in between, write-confirmation semantics vary by vendor. Some expose idempotency controls, some process writes through background jobs, some do not document the model. Ask each vendor how a write is confirmed and how duplicates are prevented, because the answer is the difference between posted to the books and accepted into a queue.

Tax and currency divergence. QuickBooks and Xero calculate tax on different bases with different rounding. Pre-computed totals pushed into the ledger create cent-level mismatches that auditors notice.

Routing the write to the source changes the shape of this. The ledger's own validation runs at write time: double-entry balancing, period locks, tax calculation, duplicate detection. An unbalanced journal is rejected by the source system and you see that error now rather than in a sync log tomorrow. The same architecture means no customer financial data rests in the integration layer. Minimal operational metadata persists, encrypted at rest with AES-256. That is the posture an enterprise security review is built to find, alongside SOC 2 Type II, GDPR, CCPA, HIPAA and PIPEDA, named US, EU and AU regions, and Secrets Manager key storage on the Pro and Scale plans.

What does the capability matrix show?

Per-field read and write support, per integration, published before you build. The full matrix covers every accounting integration and filters by data objects, readable fields, writable fields, webhooks and list parameters.

Support varies by integration; check the integration's Feature Support tab. Two ledgers are worth pausing on. NetSuite is the platform every vendor lists and few support deeply. QuickBooks Desktop still runs a large share of US SMB accounting, and few unified APIs publish its field-level support at all.

Writes are supported on every major ledger, including QuickBooks Online, QuickBooks Desktop, Xero, NetSuite, Sage Intacct, Zoho Books, MYOB and Microsoft Dynamics 365 Business Central.

Journal entry write is the depth signal worth checking on any vendor. It touches the general ledger directly, it is the operation cache-based platforms most often gate or route through background jobs, and it is the one finance teams scrutinise hardest. Support varies sharply by ledger, because it varies sharply in the ledgers' own APIs, and the matrix shows which before you build rather than during implementation.

One object-model note that prevents a misreading. The Transaction object is a ledger-line read abstraction. Entering transactions happens through the objects accountants recognise: invoices, bills, journals and expenses, which is where the write support lives. The computed statements are read-only by design: reports, balance sheets, trial balances, profit and loss and cash flow, because the ledger computes them rather than accepting them. Their coverage is narrower than the transactional objects: all five are available on QuickBooks Online, all but cash flow on Xero, profit and loss on NetSuite, and none on Sage Intacct or QuickBooks Desktop.

How do you find out when something changed?

Through virtual webhooks, because most accounting platforms publish no native webhooks at all. The ledger has no built-in way to tell your application that an invoice was paid or a transaction posted.

Unified.to closes that with virtual webhooks: change detection on a configurable interval, as frequent as every minute on paid plans, delivered to your endpoint with the changed records in the payload. There is no follow-up fetch and no polling logic in your application. Where a ledger does publish native webhooks, those arrive on the same event model, so your code never branches on which delivery path an integration uses.

One honest limit, and it is the clearest thing a cached copy buys. Interval detection surfaces creates and updates. Deletions are the exception: virtual webhooks detect them by polling on ten integrations across the catalogue, and native delete events arrive where the source sends them. A vendor that syncs into its own store can catch deletions where it checks for them: Codat on every accounting integration it syncs, Rutter on four or five ledgers. If your product has to know when a record disappears from the ledger, check that specific platform on any vendor before committing.

How fresh is the data on each platform?

Does routing every request add latency?

A routed read costs whatever the source ledger costs to answer, plus a bounded hop through the integration layer. The hundreds of milliseconds sometimes attributed to this architecture are mostly the source system's own response time. NetSuite, QuickBooks and Xero are not uniformly fast, and a cached architecture hides that latency by serving an older copy.

Figures circulating in 2026 vendor comparisons, roughly 800ms to 1.5s of overhead, carry no published methodology and bundle the source API's latency with the integration layer's. They also tend to appear in material from vendors whose own architecture routes requests the same way, where the same number would apply.

For accounting specifically that trade is rarely the deciding one. Correctness is. A write confirmed against a cache is a belief about the ledger; a write confirmed against the ledger is the ledger's answer.

If nothing is stored, am I bound by QuickBooks' rate limits?

On direct API calls, yes, and it is worth saying so plainly. Rate limiting is two layers: the integration layer's own limit, and the source platform's, which Unified.to's documentation names as the primary limiting factor. A cached architecture absorbs the source platform's limits during its sync and serves reads from the copy, which is a real benefit of holding one.

The documented remedy is the webhook path rather than a workaround. On a webhook subscription Unified.to handles pagination, rate limiting, backoff and retries server-side, and the delivery system adjusts to each platform's limits. The pattern that follows is bulk and ongoing data over webhooks, and direct calls where you need a current answer at the point of decision.

What happens when the unified model does not cover a field?

On Unified.to, you reach it on the same request rather than registering a configuration in advance.

The common objection to any unified model is that it flattens to the lowest common denominator and hides the platform-specific fields you need. fields=raw returns the source object alongside the unified one, a raw object in the write payload carries integration-specific fields and can override mapped ones, 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. No registration step, no configuration endpoint, no resync.

That matters more than it sounds, because the common case at the edge of a unified model is not a missing endpoint. It is a missing field.

How should you evaluate any unified accounting API?

Start with whether per-field write capability is published, because it predicts most of the rest. Seven questions cut through the marketing regardless of which vendor you pick.

How do you find out which fields are writable, and when? Not whether the vendor supports writes, but which fields are writable, read-only and required on create, per integration. Some publish it as a matrix you browse before you build. Some return it per connection at runtime, which works but means you cannot scope the project until you have connected an account. Some do not answer it until implementation.

Which objects can you write, on the specific ledgers your customers run? Invoice and bill writes are broadly supported. Journal and contact writes vary sharply by ledger. Get the per-integration answer in writing.

What happens at the edge of the unified model? Three questions rather than one, because asking only about custom fields is a test most vendors pass. Do you support custom fields. Do you give me the original source data. And can I reach the endpoints you have not unified. Ask all three and ask what each costs, because some vendors answer yes to all of them and gate the answers behind a plan.

Where does financial data rest, and what certifications back it? One model keeps customer books out of the integration layer; the other puts the vendor inside your customers' compliance scope. Neither is wrong, and one extends your enterprise security reviews. On certifications, Codat, Merge, Rutter and Truto hold ISO 27001 and Unified.to does not, so if your buyer's security review treats it as mandatory, check it first.

How is a write confirmed? Synchronously against the ledger, or accepted into a queue and reconciled later? Ask how duplicates are prevented and what your retry logic operates on.

What is the freshness model? Live reads, or scheduled syncs with cadence tied to tier? For reconciliation against a live ledger the difference is correctness rather than speed.

Are premium ledgers surcharged, and what does the entry tier exclude? NetSuite and Sage Intacct are where some pricing models add per-ledger fees or throttles. Merge prices on linked accounts rather than ledger tier, so the surcharge does not arise, but its published tier excludes passthrough, remote fields and custom sync frequencies, and the tiers that include them are contract-based. Unified.to prices on API calls with all integrations and all escape hatches available on every plan. Rutter and Codat publish no pricing (Rutter bills per 'billable connection'), so ask directly.

Ask the same question about growth, and note that the axis differs by vendor. Merge bills per connected account. Codat bills per active company per month plus an annual platform fee. Truto bills per connector, from $999 a connector a year with a ten-connector minimum (as of 8 October 2026), so the floor is roughly $10,000 before a single customer connects. Unified.to bills on API calls. Work out the bill at the customer count you are planning for rather than the one you have, and ask what happens at the point the published rates stop. For how per-connection, per-consumer and usage-based pricing scale from 100 to 10,000 customers, see usage-based vs. per-connection pricing.

Codat, Rutter, Merge, Apideck or Truto: which fits which product?

Codat is a financial data platform for banks and lenders, and says so: as of 8 October 2026 it calls itself "an advisory intelligence solution purpose-built for modern commercial banking" and lists "Not a universal API" among its boundaries, with packaged lending, underwriting and spend-insights products on top. For a lender underwriting SMB credit on historical financials, that solution depth is the right evaluation.

For a B2B SaaS product reading and writing invoices, bills and journals across customers' ledgers, the fit is different. Codat withdrew its public Accounting API reference on 16 September 2026; the specification on GitHub still says it is "relevant only to our existing clients" and directs new enquiries to a Codat contact. The products for technology teams are use-case bundles: Bank Feeds, Lending, Expenses and Bill Pay. There is no receivables product. Codat lists 17 accounting platforms (one, Workday, for its Spend Insights product only; as of 8 October 2026), and publishes no per-platform coverage table for its standard data model. The architecture underneath is a cache, with sync defaulting to none per data type until configured and weekly as the recommended cadence (as of 8 October 2026).

Two things Codat does better. Its Accounting API, which it reserves for existing clients, has a wider object model, with 26 endpoint groups including item receipts, items and payment methods. And because it diffs against a stored copy, it flags deleted records on every accounting integration it syncs, regardless of whether the source supports it.

Codat vs Unified.to

Rutter unifies commerce, payments, accounting and ads with a fintech and lending orientation, and is a strong fit for merchant-underwriting and commerce-finance products. Writes pass directly to the platform. Reads come from Rutter's store, on a cadence their own pages do not agree on. Rutter publishes a coverage explorer per endpoint and per platform, and its API spec marks support per field, with platform validation rules (as of 8 October 2026). Their accounting product page lists 41 platforms against 23 on their integrations catalogue, and their published totals range from 20+ to 75+ depending on the page.

Two things worth knowing. Rutter's write coverage on the four major ledgers is deep: its spec lists create, read, update and delete on invoices and bills across NetSuite, QuickBooks Online, Xero and QuickBooks Desktop (bill delete except QuickBooks Desktop), and create and update on customers (8 October 2026). They also ship bank feeds, covered under the requirements below. And their accounting build runs into enterprise ERP with real API depth, including SAP S/4HANA, Acumatica and SAP Business One; its accounting page also lists SAP Ariba, Infor, Deltek Costpoint and Microsoft Great Plains with no docs or API support published (8 October 2026). Rutter emits delete events on four or five ledgers (QuickBooks, QuickBooks Desktop, NetSuite, Xero and, per its docs, Sage Intacct v2), with the record's final state.

Rutter vs Unified.to

Merge is the multi-category default: accounting alongside HRIS, ATS, CRM, ticketing, file storage, knowledge base and chat. Eight categories, and none of them is payments, commerce, shipping or advertising, so a product that needs accounting now and payments later adds a second vendor.

As of 2 October 2026 Merge lists 16 accounting integrations, including Oracle Fusion Cloud ERP, which it added in beta. As of 8 October 2026, Unified.to supports all 16.

Merge publishes supported-fields matrices per integration and, through /meta/post and /meta/patch on every writable accounting model, returns field types, a required array and conditional parameters per linked account at runtime; Unified.to publishes per-integration Feature Support. Both are legitimate and they suit different buying processes.

Merge stores a synced copy and serves normalized reads from it, and their remote-data documentation notes that the integration's own fields update only when a unified model field changes, so the source fields can lag even when you ask for them. Merge syncs daily on Launch, and up to each integration's published Highest setting on Professional and Enterprise, where Remote Data is also available.

What does Merge cost at scale?

As of October 2026, Merge publishes its pricing at $650 a month for up to 10 production linked accounts and $65 per linked account after that, with three free. The billing unit is the connected account, and the arithmetic is worth doing before you sign: 50 connected customers, each with one linked account, is $3,250 a month at those rates, or $39,000 a year, and 100 is $6,500 a month, or $78,000 (our calculation). Merge invites a volume conversation past that point, which is where the published numbers stop.

Two things compound it. The published tier is the entry tier, and Professional and Enterprise are contract-based with no figures on the page. And the entry tier is where the escape hatches are not: remote data, remote fields, passthrough and custom sync frequencies all require Professional or above. A team that hits an integration-specific field on Launch upgrades to reach it, into a tier with no published price.

Unified.to bills on API calls, with customer connections unlimited on every plan and the Passthrough API and custom and original fields included on all three tiers. Cost tracks how much you use rather than how many customers have connected, which is the difference that shows up when a product succeeds. Two recruiting products have written about hitting that wall on this category's pricing model: Breakthrough Jobs switched after finding per-connection pricing did not scale with them, and RecView reported a Merge quote of over $30,000 in platform fees before choosing Unified.to.

Merge vs Unified.to

Apideck shares the routed-request posture and stores no customer business records (QuickBooks Desktop excepted), though its logs capture full request and response bodies by default. Two differences decide it. Structure: Apideck runs accounting and e-commerce as separate unified APIs (its Ecommerce API is in beta as of 8 October 2026) with separate object models, so reconciliation across the commerce-to-ledger boundary spans two integrations and two schemas, where Unified.to models the ledgers and the commerce and spend platforms feeding them in one category and one object model. And access: category count is gated by plan, with one unified API category on the entry tier and three at the next. Apideck's accounting objects are worth a look on their own merits, because they embed display labels beside foreign keys, so an invoice renders in fewer calls. As of 8 October 2026 their accounting connectors page lists 54 or more platforms.

The fact most likely to decide it is hosting, covered under the requirements below. Their subprocessor list and their published static IP addresses both confirm the EU-only position.

Apideck vs Unified.to

Truto routes requests the same way by default and leads with per-tenant schema customisation through JSONata, applied at platform, environment and account level and deep-merged at runtime. That is a real capability, which Truto's case studies credit in general terms as customisation, and it pairs Truto-built base mappings with overrides you maintain. Their documentation is also worth reading on its own merits: the rendered invoice create page attributes support to individual integrations field by field (as of 8 October 2026), which is finer granularity than most vendors in this category publish.

Two things to check against your requirements. First, the accounting model has structural limits worth reading before you build: a payment references exactly one invoice or bill with no allocation amount, so split and partial payments are not representable in the unified model; there is no separate bill object, with accounts payable expressed as a type on invoice; and journal entry lines carry no debit and credit fields. Second, depth varies by ledger. As of 8 October 2026, their unified accounting API covers 12 integrations in its docs (11 on its marketing page), against a 35-connector accounting directory where the rest are reachable through the proxy without a unified accounting schema. Releases between 14 September and 5 October 2026 deepened the top of that list: QuickBooks Online and Xero gained write operations, Zoho Books (Beta) now has create, update and delete on 16 of its 17 resources, Dynamics 365 Business Central lists 18 resources with writes on 13, and NetSuite, Sage Intacct, FreeAgent and Sage Business Cloud Accounting gained payment writes. Below that, gaps remain: NetSuite writes only accounts and payments, Wave reads only accounts and contacts, Brightpearl reads no invoices, and Coupa reads no payments.

Truto vs Unified.to

Chift and regional players focus on European accounting tools, worth a look in DATEV and Fortnox-heavy markets.

Why does the accounting category include Stripe and Shopify?

Because the highest-volume accounting integration use case in B2B SaaS is reconciliation across that exact boundary.

The 231 integrations include the ledgers and also Stripe, Shopify, Amazon Seller Central, BigCommerce, Toast, Bill.com, Brex, Ramp, Expensify and Concur. Payouts, orders, fees and expenses originate in commerce and spend platforms and are posted into ledgers as invoices, bills and journals. One category and one unified object model covers both sides of the entry, rather than an accounting API for the ledger and a separate commerce API for everything feeding it.

Which one should you choose?

Three requirements settle it before anything else

Bank feeds written into a customer's ledger. Codat, Rutter and Apideck ship them; Unified.to's docs list no bank-feed writes (as of 8 October 2026). Codat writes into six ledgers, Apideck into 17 with the feature in beta (as of 8 October 2026), and Rutter runs bank feeds as its own product. Codat documents the gating as Intuit and Xero partnership approval rather than engineering, which is why this is a no-build for a vendor that does not already hold those partnerships rather than a roadmap item.

A general-purpose accounting API you can buy today. Codat's is "relevant only to our existing clients" (specification), and Codat withdrew its public reference on 16 September 2026. If you are a new customer who needs one, Codat is out regardless of everything else on this page.

US or APAC data residency. Apideck hosts in the EU only and lists region selection as No, at every tier including Enterprise. No budget resolves that one.

Then the weighting

Codat is for lenders, banks and credit platforms underwriting on SMB financial data, with packaged lending and insights products built for that buyer. It is not for a product that needs to write invoices, because there is no receivables line.

Rutter is for fintech underwriting commerce merchants that need commerce and accounting in one fintech-oriented model, with integrations into mid-market and enterprise ERPs such as SAP S/4HANA, Acumatica and SAP Business One. It is not for a product that needs categories outside commerce and finance.

Merge is for products where accounting is a second category on a platform already adopted for HR or ATS, or where Merge Agent Handler already governs agent tooling. It is not for a buyer whose next category is payments, commerce or shipping, because Merge publishes none of those.

Apideck is for products built around an embedded integrations marketplace, where Vault is the customer-facing surface. It is not for a product whose accounting and commerce data need to reconcile in one object model, because those are separate unified APIs.

Truto is for teams that want per-tenant schema control through JSONata and are willing to maintain their own mapping overrides. It is not for a product that needs to represent a payment split across several invoices, which their unified accounting model cannot express.

Unified.to is for B2B SaaS and AI products that write into their customers' ledgers and need the write to land in the books rather than in a vendor's database. Where a vendor holds a copy, the write can be applied to that copy first and the system of record finds out on the sync cycle, so for some window your application, the vendor and the ledger disagree. It varies: Merge and Rutter pass writes straight through to the source, and others do not document the model at all. Ask, because here the ledger validates the write and answers.

Two capabilities follow from that, and no other vendor in this comparison matches either as of 8 October 2026. Reconciliation across the commerce-to-ledger boundary happens in one object model on one connection, because the ledgers and the Stripe, Shopify and Brex platforms feeding them are the same category; Apideck and Truto both run accounting and commerce as separate unified APIs. And change detection runs on a one-minute minimum, against alternatives ranging from five-minute scheduled syncs (Truto's opt-in RapidBridge, and a figure on Rutter's product page; its docs default to 60 minutes and its API accepts 60 to 20,160) to a weekly recommendation.

The pricing model is the third reason and it is about alignment rather than price: connections and customers are unlimited on every plan and you are metered on API calls, where a per-connection model makes every customer who connects a billable unit. Every category is on every plan when your roadmap moves past accounting.

It is not for a lender underwriting on historical financials, and not for a team that wants a stored copy to diff for deletions.

Moving from another unified API? Unified.to publishes migration guides for Merge, Rutter and Apideck, plus an overview for other platforms; each maps authorization, API calls, pagination, webhooks and passthrough, and covers re-authorizing customers or importing credentials from your own OAuth apps.

Start a 30-day free trial · Book a demo

Frequently asked questions

What is the best unified API for accounting integrations?

It depends on the workload. Unified.to fits B2B SaaS products writing into customers' ledgers, with 231 accounting integrations, requests routed to the source, and usage-based pricing with unlimited connections. Codat fits banks and lenders underwriting on SMB financials. Rutter fits commerce-plus-accounting fintech. Merge fits read-heavy products where accounting sits beside HR, ATS or CRM. Apideck fits products built around an embedded integrations marketplace.

Which unified API supports writing invoices, bills and journal entries to QuickBooks, Xero and NetSuite?

Unified.to supports writes on all three objects across all three ledgers, with per-field support documented in the capability matrix. Merge, Apideck and Rutter also support core receivables and payables writes; Codat has no receivables product; its invoice writes exist only on its Accounting API, which Codat marks "relevant only to our existing clients". Merge publishes supported-fields matrices per integration and returns per-field write capability at runtime through /meta. Rutter publishes write support per endpoint and per field in its API spec.

Does Unified.to support QuickBooks Desktop?

Yes, including payment allocation, credit memo applications, dimension references and payment terms. Support varies by integration; check the integration's Feature Support tab.

How are duplicate writes prevented?

The ledger's own validation runs at write time, because the write executes against the source API directly and there is no intermediate queue replaying jobs. Your application receives the ledger's response synchronously, so retry logic operates on confirmed state rather than on a cache's belief about it.

Can I write custom or platform-specific fields?

Yes, through the raw object on the write payload, which carries integration-specific fields and can override mapped ones. For endpoints with no unified object, the Passthrough API reaches them on the same connection in either direction.

Sources: Unified.to documentation, capability matrix and first-party exports; Codat, Rutter, Merge, Apideck and Truto published documentation. All checked 6 August 2026; Merge, Apideck, Rutter, Truto and Codat figures rechecked 8 October 2026.

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.