Rutter vs Unified.to: which should you use for accounting and commerce integrations? (2026)

August 4, 2026

Rutter and Unified.to both cover accounting, commerce, payments and advertising integrations. The difference is where your customers' financial records rest. Rutter caches a copy into its own infrastructure and serves your reads from it. Unified.to routes each request to the source API and keeps nothing, so a read returns the ledger as it stands at the moment of the request and no copy of your customers' records sits with a third party.

For most products the answer is Unified.to, and the reason is custody rather than speed. There are five situations where Rutter is the better choice and each is specific: bank feeds, mid-market and enterprise ERP coverage, payment reconciliation on two named ledgers, Clover commerce data mapped to unified objects, and ISO 27001 as a procurement requirement.

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

How do Rutter and Unified.to compare?

Rutter and Unified.to differ on four things that change a build decision: where the data rests, how much they cover, what it costs, and what happens when you need something the unified model does not include.

What is the architectural difference between Rutter and Unified.to?

The difference is custody: Rutter holds a copy of your customers' accounting records and serves your reads from it, while Unified.to routes each read to the source API and holds nothing. Both check on a schedule where a source API has no platform-native webhook, so scheduled checking is not what separates them. Where the records rest is.

Rutter documents the sequence, though not consistently. Their API basics page says the initial sync may take hours to days depending on the size of the data. Their connection lifecycle page says the same sync might finish instantly or in a few hours. Requests made before it completes return a PRODUCT_NOT_READY error, and force_fetch=true returns data anyway with the caveat that it may be incomplete. Once the initial sync finishes, Rutter begins running a continuous data sync every 60 minutes. (Rutter API basics, connection lifecycle)

What does holding a copy actually change?

A cached copy has three properties a direct read does not: an age, an owner, and a build time.

It has an age because it refreshes on an interval rather than when you read it. It has an owner because it sits in Rutter's infrastructure as a sub-processor in your compliance chain. And it has a build time because the initial sync runs before your first read returns anything.

One qualifier on build time. Rutter lets you split the initial sync into configured batches with a chosen history window per batch, and the connection becomes usable when the first batch completes rather than when the full history lands. Their own worked example loads six months of expenses first, and the connection is ready from there while eighteen further months load behind it. The configuration is itself work: which objects, in which order, over how many months, decided before you know what your product will query. A routed read has no equivalent setting because there is nothing to preload.

Freshness is the weakest of the three properties, and the only one most comparisons mention. It is also the one Rutter's own pages disagree about, covered below. The other two do not depend on the cadence at all, and they do not move when you tune it.

On Unified.to, your server calls the API with a connection ID, Unified.to transforms the call into the source API's format and routes it to the source, then transforms the response in memory into a unified object and returns it. There is no initial sync to wait through and no last_synced_at field to reason about, because nothing sits between the source and the response. Where a source API supports paging and filtering, Unified.to transforms your parameters into whatever that API expects, so one paging model works across integrations that implement paging very differently. (Technology overview)

The copy does buy Rutter something real. Their store is pre-indexed, sortable and filterable, which matters when you are reading three years of general ledger for a credit decision. Where a field is expensive because the source API needs an extra call per record, a cache pays that cost once during the sync. Unified.to pays it at request time and makes the choice explicit: those fields are excluded by default and returned when you ask for them with the fields parameter, with the default set per workspace. On latency-sensitive traffic you leave them out. On a backfill you turn them on. (Slow fields)

When does cached accounting data actually cause a problem?

Cached reads become a correctness problem when a decision is made from the data and then written back within the refresh window. Underwriting tolerates an hour-old balance. Accounts payable does not.

Consider an AP automation product approving a payment run. It reads open bills, an approver clears them, and the product posts payments. If a bill was paid directly in QuickBooks forty minutes ago and the cache has not refreshed, the product pays it twice. The error is not latency. It is a duplicate payment in a customer's ledger, and it surfaces at reconciliation rather than at the moment it happens.

The same applies to an AI agent. An agent reasoning over accounting data has no way to tell an old balance from a current one, because both arrive as a number. Where the agent then writes, the refresh interval becomes the window in which it can be wrong.

How often does each one detect changes?

Unified.to documents a one-minute minimum interval on paid plans. Rutter's documentation states a 60-minute continuous sync, and their Rutter Link product page states that data is refreshed with a cadence of down to five minutes. The two figures are not reconciled on any published page, and no page states whether the faster figure is configurable, tiered or platform-specific.

What you can set the interval to on Unified.to is not governed by what each check costs, because a check that finds no change is not billed. Billing is on API calls, and an empty check is not one.

Rutter offers platform-native webhooks for two platforms, QuickBooks Online and Xero. For every other integration, changes surface on the sync cadence. Their own guidance is not to depend on webhooks alone: their documentation states that it is not recommended to solely rely on webhooks to ingest data from Rutter, and recommends a cron job polling last_synced_at_min instead. (Syncing Rutter data)

That recommendation follows from their retry policy. Rutter retries a failed webhook six times over roughly fifteen minutes on exponential backoff, then marks it failed and stops. Past that window the polling job is the only route by which the event is recovered.

Does the read-path difference apply to writes as well?

No. Both Rutter and Unified.to send writes directly to the source platform, so the custody difference is a read-path difference only.

That is not true of cache-based vendors generally. Many hold a write in their own database and reach the source on the next sync, which can be up to 24 hours. Rutter does not. Their write endpoints pass requests directly to their respective platforms and are subject to each platform's rate limits, and their default response_mode=prefer_sync returns a synchronous result if the platform responds within 30 seconds. (Rutter asynchronous operations)

If you are evaluating on write behaviour alone, architecture is not the deciding factor between these two. Object coverage is.

Which one covers more accounting, commerce, payments and ads integrations?

Unified.to covers more in all four categories, and the gap widens as you move away from accounting. As of August 2026:

Counts alone invite an obvious reply, which is that enough engineers can build any number of integrations. That reply holds within a category and breaks across them. Building several hundred integrations inside one category is a different problem from building them across 32, and the reason is architectural: because reads route to the source, there is no sync pipeline to build per integration, and authorization, change detection and unification happen once at the platform layer rather than once per source.

Both cover the ledgers that decide most deals: QuickBooks Online, QuickBooks Desktop, NetSuite, Sage Intacct, Xero and Dynamics 365 Business Central.

Taking Rutter's catalogue as the checklist, Unified.to covers 59 of their 72 platforms: 29 of 41 in accounting, 23 of 24 in commerce, 8 of 9 in payments, and all 3 in advertising. Outside accounting the only gap is Clover.

Rutter's accounting build runs deep into mid-market and enterprise ERP. Unified.to carries the spend and expense layer that sits beside the ledger and Rutter does not: Bill.com, Brex, Ramp, Expensify, Concur and Rydoo, plus Epicor Kinetic, Sage 100 and Unit4 ERPx. An AP automation or spend management product reads both layers.

Rutter's published integration counts do not agree with each other

Rutter publishes four different figures for the same catalogue. Their homepage hero says 75+, their homepage product section says 60+, their demo page says 40+, and their trust centre says 30+. Their integrations page lists 52 tiles containing 47 unique platforms, with Stripe, Square, Clover, Chargebee and Chargify each appearing under two categories.

The 47 figure is the one to discount. Rutter's four category product pages match the integrations page exactly on commerce, payments and ads, and list 41 accounting platforms against the integrations page's 16. Their browsable catalogue shows 39 per cent of their accounting coverage, which is the category most buyers evaluate them on.

Platforms including SAP S/4HANA, Workday, DATEV, Pennylane, Campfire, DualEntry, Rillet, Lexware, Fortnox, MYOB and Dynamics 365 Finance and Operations appear on Rutter's accounting product page and their documentation, and not on their integrations page. If you are checking whether Rutter supports a platform, check their product pages and documentation rather than the catalogue browser.

In May 2026 Rutter published their work on Coverage Agents, using AI subagents to build integrations end to end, and named eight shipped that way. Both catalogues are being generated now, so treat any count as a snapshot.

Which accounting objects does each one support?

Both cover the core accounting objects, and they divide them differently: Rutter models invoice payments and bill payments as separate endpoints and each tracking dimension as its own, while Unified.to carries payment application as an array on the payment record and all dimension kinds inside one Category object. Object count measures how a schema is divided, not what you can read.

Two honest limits on that. The type field being readable everywhere does not mean every ledger returns every one of the eight kinds, so the saving is in the shape of the work rather than in what data exists. And it is a read argument: writing a dimension onto a transaction is not available through the unified model on the major ledgers, and on Rutter the equivalent write is QuickBooks Online only.

Unified.to models eight dimension kinds as a single Category object: CLASS, DEPARTMENT, LOCATION, PROJECT, TASK, CUSTOM, EXPENSE and INCOME. (Category data model)

Unified coverage differs by ledger on both sides, so check the specific objects your product reads before choosing either.

As of August 2026, payment allocation on Unified.to is available on QuickBooks, QuickBooks Desktop, Xero and NetSuite. It is not available on Sage Intacct or Dynamics 365 Business Central. Rutter's coverage explorer lists bill_payments, invoice_payments, bill_credit_applications and invoice_credit_applications as supported on Sage Intacct.

The gaps run both ways on the same platform. Rutter's coverage explorer lists no payment_terms or payment_methods support on Sage Intacct, and no journal entry attachments. Unified.to reads payment_terms on bills, invoices and contacts there, and journal attachments.

Both vendors are shipping against these gaps. Rutter's changelog records a Sage Intacct V2 track adding a custom fields endpoint on 2 July 2026 and user-defined dimensions on bills and expenses, so the version you are quoted matters when you compare object coverage on that ledger.

How do you load historical accounting data without a cache?

Unified.to loads history through a webhook subscription with include_all set, which returns all existing data for the connection to your endpoint. Unified.to handles pagination, rate limiting, backoff and retries server-side, so your database ends up in the same state as it would after Rutter's initial sync, without a copy being retained on the vendor side.

Each page of the backfill arrives marked INITIAL-PARTIAL, and the final page is marked INITIAL-COMPLETE, so your ingestion knows when it has the full set. Rutter marks its batched backfill the same way, with INITIAL_UPDATE and HISTORICAL_UPDATE. The difference is not the marking. It is that one delivery leaves a copy behind and the other does not. (Create a webhook subscription)

The same subscription then delivers ongoing changes, and the changed records travel in the event payload. There is usually no follow-up fetch, because the event carries the data rather than a pointer to it. Platform-native and virtual webhooks arrive on the same event model, so your code never branches on which delivery path an integration uses. (Understanding virtual webhooks)

If queryability is why you were considering a cached vendor in the first place, there is a third option. Database Sync is a webhook with a database destination: Unified.to creates the tables from the unified models, including sub-tables for arrays and associations, and writes records into your own database as they change. Subscriptions take a fields parameter, so a delivery carries the fields your consumer needs and leaves out the expensive ones unless you ask for them. You get the indexed, filterable, joinable copy a cache-based vendor offers, except it sits in your infrastructure rather than theirs. Rutter has no equivalent.

One honest limit, and it is the clearest thing a cache buys. Where a platform has no native webhook, Unified.to detects changes on an interval and delivers the event, and interval detection surfaces creates and updates. Delete events are the exception: across the major ledgers they are available on QuickBooks Online only, on contacts and invoices. Rutter's sync computes a diff against its stored copy, which is what lets it emit delete events across its catalogue. If your product has to know when a record disappears from the ledger, that is a real reason to prefer a stored copy, and it is worth checking per platform on either vendor before committing.

Use webhooks for bulk and ongoing data, and direct API calls where you need a current answer at the point of decision. You are not choosing between them.

What happens when you need data outside the unified model?

Every unified API models a subset of what each platform publishes, so the more useful question is what happens at the edge of that subset. On Unified.to the unified layer is a convenience rather than a ceiling: every part of it has a documented bypass that runs on the same connection. Rutter has a field-level bypass on writes, and beyond that its answer is to return your credentials.

Where an entire endpoint has no unified object, the Passthrough API sends a request to it using the connection you already have. You give the connection ID, the platform path and any method, headers, parameters or body; Unified.to authenticates with the stored credentials, routes the request and returns the response unmodified. (Passthrough API) The response is the platform's own schema, so formats, pagination and errors vary and you handle them. Unified objects are what remove that work. Passthrough is what stops an unmapped endpoint from being a blocker.

Which objects are mapped does not limit what the connection can reach. What limits it is the OAuth scopes granted at authorization, so request the scopes your product will need up front, including any platform-specific ones, rather than discovering the boundary later. (Understanding scopes)

Rutter's Connection Credentials Passthrough returns the underlying API keys and tokens so you can call the platform directly. (Rutter passthrough) That is an exit rather than an extension: you leave Rutter, manage those credentials yourself, and own the platform relationship from there. Their field-level passthrough is the closer equivalent, and it applies to writes on accounting platforms rather than across the catalogue.

What does each one cost?

As of August 2026, Unified.to publishes three tiers starting at $750 a month for 750,000 API calls. Rutter publishes no prices, and the ledgers most buyers evaluate it for sit behind a custom quote.

Rutter's pricing page lists a 30-day free trial and a custom quote. The free trial gives sandbox data plus QuickBooks, Xero, Freshbooks and Zoho Books. Everything else, described on their page as access to all platforms including NetSuite, QuickBooks Desktop and Sage Intacct, requires the quote. (Rutter pricing) The four platforms you can self-serve are SMB ledgers. The three named behind the gate are the ones a mid-market or enterprise product needs.

Rutter does state its pricing drivers, in the FAQ on their homepage: price depends on the volume of connections, growth in that volume over time, product capabilities, and the platforms you integrate with. Three of those four scale with something other than how much you use the API. No unit and no figures are published, so what a connection costs is a question for their sales team. The general case is covered in usage-based versus per-connection pricing for integrations.

How do the two compare on security and compliance?

Rutter publishes SOC 2 Type II and ISO 27001:2022, with current certificates and annual penetration tests through 2026. Unified.to publishes SOC 2 Type II, CCPA/CPRA, PIPEDA and HIPAA with a BAA available on the Scale plan. Both publish GDPR. Unified.to does not hold ISO 27001, and if that is a procurement requirement for you, Rutter meets it and Unified.to does not.

Where the two differ most is custody rather than certification. Unified.to holds no end-customer data. The only things that persist are the connection ID and minimal operational metadata, meaning request status, timestamps and paths, encrypted at rest with AES-256. Request and response bodies are never written to logs. (Unified.to security)

That holds even when delivery fails. A webhook retry holds a cursor rather than your records: each attempt re-reads the page from the source and dispatches it fresh, so nothing sits in a delivery queue.

Rutter's trust centre lists the controls that follow from holding the copy: datastores housing sensitive customer data encrypted at rest, formal retention and disposal procedures, and purging customer data from the application environment when a customer leaves. Those are the right controls to have. They are also the ones you inherit as a reviewer, because each is a commitment about records that exist.

The practical consequence is what a security review has to cover. Rutter is a data processor holding copies of your customers' financial records, which makes it a sub-processor to scope, reconcile, secure and delete. Where nothing is held, there is nothing to scope, nothing to delete, and no data migration if you later change vendors. Unified.to operates in named US, EU and AU regions on every plan, including Grow at $750 a month. Rutter does not specify a region on its trust centre or its site.

What happens when you need something outside accounting and commerce?

With Rutter you add a second vendor for most categories. Rutter's published product surface is accounting, commerce, payments, ads and bank feeds, and their documentation has begun shipping HRIS platform guides for Gusto, Rippling and Deel with employee, department and organization endpoints in their July 2026 changelog entries, ahead of any HRIS category appearing on their API reference. Unified.to covers the four plus 28 more API categories on the same authorization model and the same schema, at no additional cost per category.

The reach shows up on a single connection. A Unified.to connection to Sage Intacct carries accounting, e-commerce, tasks, HR and directory, file storage and passthrough objects on one authorization.

Finance products reach outside finance early. An AP automation product pulling receipts out of Google Drive or SharePoint needs file storage. A spend management product notifying an approver needs messaging. A support-facing finance product needs ticketing. None of those are accounting integrations, and all of them are on the critical path of an accounting product.

One honest counterweight. Cross-category access is free on the pricing, and it is not free in developer effort. A team building a finance product has to find that departments live under the HRIS models, activate that category, and reconcile identity across the two. That is a documentation problem before it is a schema one.

The relevant question is not how many categories exist. It is whether the second thing your roadmap needs is inside your vendor's boundary or outside it.

Does Unified.to support bank feeds?

No. Rutter offers bank feeds and Unified.to does not. If your product needs to write bank transactions into QuickBooks, NetSuite, Sage Intacct or Xero, Rutter is the correct choice.

Bank feeds is six objects on Rutter's API, covering accounts, contacts, one-time passwords, payment networks, transactions and transaction attachments, and the barrier is commercial rather than technical. Their documentation states that bank feed APIs are restricted to certified financial institutions with established partnerships, and that forming partnerships with Intuit and Sage is time-consuming and gated to major companies. Rutter holds those partnerships. (Rutter bank feeds)

Unified.to has not built this and does not intend to. It is a partnership process, not an engineering one.

Which one works better with AI agents?

Unified.to's MCP server has been deployed since June 2025 with a public changelog of dated releases, and supports read and write actions across 675 integrations. Rutter describes Rutter MCP as its emerging Model Context Protocol layer for finance in a July 2026 blog post, with no product page or documentation published.

As of July 2026 the Unified MCP server exposes 43,456 actions, of which 8,242 are unified across integrations. The remainder are the platforms' own API surfaces, off by default and enabled with a single parameter when an agent needs something the unified model does not cover. An agent can retrieve a candidate, update a deal or post a journal entry through the same server, using the connection authorized for each integration.

Access is scoped rather than all-or-nothing. A connection-scoped signed token grants an agent access to one connection and nothing else, a permissions list narrows which tools appear, and hide_sensitive strips PII fields from results before they reach the model. That is the difference between an agent that can reconcile invoices and one that has also read every contact's email address and phone number.

An agent cannot inspect the age of the data it reasons over. Where reads come from a store that refreshes on an interval, every agent decision inherits that interval as a margin of error, and the agent has no way to detect it. Where each read reaches the source API, the answer is current as of the request.

Rutter ships Embedded ERP and Agentic Commerce today, both built on their existing APIs. As of August 2026, emerging is Rutter's own word for their MCP layer, and there is nothing published to build against.

When should you choose Rutter over Unified.to?

Choose Rutter where your product needs bank feeds, one of the mid-market or enterprise ERPs Rutter carries and Unified.to does not, payment reconciliation on Sage Intacct or Dynamics 365 Business Central, Clover commerce data mapped to unified objects, or ISO 27001 as a procurement requirement. Each is narrow enough to check in a few minutes.

Bank feeds. Rutter offers them and Unified.to does not, at all. If your product writes bank transactions into QuickBooks, NetSuite, Sage Intacct or Xero, the comparison ends here.

Mid-market and enterprise ERP. As of 6 August 2026, nine ERPs on Rutter's accounting product page are not on Unified.to's catalogue: SAP Business One, SAP Ariba, Oracle Fusion ERP Cloud, Infor, Deltek Costpoint, Certinia, Rootstock, Priority ERP and Microsoft Great Plains. Rutter also carries Fulfil, Finaloop and Digits. If your product connects to any of these, check the current position on Unified.to's integrations page before ruling either vendor in.

Payment reconciliation on Sage Intacct or Dynamics 365 Business Central. Rutter supports it on both. As of 6 August 2026, Unified.to's payment allocation covers QuickBooks, QuickBooks Desktop, Xero and NetSuite.

Clover commerce and payments data mapped to unified objects. Both vendors have Clover. Rutter has mapped its commerce and payments endpoints. As of 6 August 2026, Unified.to's Clover objects are HRIS Employee and Timeshift, with Passthrough reaching the rest of the Clover API. If you want Clover sales or payment data arriving already mapped, Rutter has it today.

ISO 27001 as a hard procurement requirement. Rutter holds ISO 27001:2022. Unified.to does not.

Two further cases are worth knowing about. As of 6 August 2026, financial statement objects are available on Rutter's Sage Intacct integration and not on Unified.to's, where profit and loss, balance sheet, trial balance and cash flow are available on QuickBooks Online, and all but cash flow on Xero. And heavy analytical querying against large accounts, where the data can be an hour old, is what Rutter's store is built for. Their fintech references are strong: Mercury, Airwallex, PayPal, Payoneer and Parafin all appear on their homepage.

Coverage moves on both sides. Every capability statement above carries the date it was checked, and the current position is published on each vendor's own integration pages. Unified.to's Sage Intacct integration page lists the live objects, methods, readable and writable fields for that ledger, and there is an equivalent page for every integration.

When should you choose Unified.to over Rutter?

Start here: does your product need anything outside commerce and finance? Rutter publishes five categories: accounting, commerce, payments, ads and bank feeds, with HRIS endpoints appearing in their documentation ahead of any category. If your roadmap includes CRM, ticketing, messaging, file storage or anything else on the list of 28 categories beyond those four, you are adding a second vendor for them, and this is settled before any other comparison.

Otherwise, six reasons:

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 any data migration if you later switch vendors, and removes the refresh interval as a source of error in any product that reads a balance and then writes back to the ledger. AP automation, spend management and AI agents taking action all do exactly that. And if queryability is what drew you to a cache in the first place, Database Sync writes the same indexed, joinable copy into your own database, with tables generated from the unified models. That is Rutter's main structural advantage, available without handing over the records.

Coverage outside accounting, and it is not close. 146 unique platforms across Rutter's own four categories against their 72: 22 advertising integrations against three, 40 payments against nine, 78 e-commerce against 24. In accounting it is 105 against 41, and that is where Rutter has built something Unified.to has not. Check both catalogues rather than either side's summary.

Change detection you can actually set to a useful interval. Rutter offers platform-native webhooks on QuickBooks Online and Xero, and its own documentation recommends a cron job polling last_synced_at_min rather than relying on webhooks alone. Unified.to detects changes on a one-minute minimum on paid plans, delivers the changed records in the payload, and does not bill a check that finds nothing, so the interval is not governed by what each check costs.

An MCP surface you can build against today. Deployed since June 2025 with a public changelog, 43,456 actions of which 8,242 are unified across integrations, with connection-scoped tokens, a permissions list that narrows the tool set and hide_sensitive stripping PII before results reach the model. Rutter describes its own MCP layer as emerging, with no product page or documentation published.

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. Fields, query parameters, write payloads, whole endpoints and OAuth scopes each have a bypass on the same connection, so an object nobody has mapped yet is a mapping question rather than a blocker.

The pricing is published. Three tiers, billed on API calls, with unlimited connections and customers. Rutter's homepage FAQ states its price depends on the volume of connections, growth in that volume, product capabilities and platforms, with no unit and no figures published. Your bill tracking usage rather than customer count is what lets you put integrations in front of free-tier users without every signup adding cost.

Frequently asked questions

Can I use both Rutter and Unified.to?

Yes, and for some products that is the right answer. If you need bank feeds, or one of the enterprise ERPs Rutter carries and Unified.to does not, that is a Rutter product with no equivalent, and it can sit alongside a broader integration layer.

Which delivery method should I use for which job?

Use direct API calls where you need a current answer at the point of decision, virtual or platform-native webhooks for ongoing change delivery, and Database Sync where you want an indexed copy in your own database. All three deliver to your infrastructure, and a webhook subscription with include_all handles the initial backfill.

What happens to my customers' credentials if we move off Unified.to?

You can export customer credentials at any time. Because no end-customer data is stored, there is no data migration to perform, only credential portability.

Does Unified.to support QuickBooks Desktop?

Yes, including payment allocation, credit memo applications, dimension references and payment terms as of the 29 July 2026 release. Change detection on QuickBooks Desktop surfaces creates rather than updates, so check that against your product's requirements.

How quickly can Unified.to add an integration we need?

Unified.to ships new integrations on customer demand. Recent additions include Acumatica, Exact Online, Rillet, Campfire, DualEntry, Shopee, Lazada, Mercado Libre and Mollie.

Related reading: Technology overview: four generations of integration architecture · Merge vs Unified.to · Kombo vs Unified.to: sync-and-store versus real-time pass-through · Truto vs Unified.to · Knit vs Unified.to

Sources: Rutter product documentation, integration and category product pages, pricing page, changelog and trust centre; Unified.to documentation, integration pages, pricing page, security page and changelog. All checked 6 August 2026.