Accounting Integration Cost: One Project per Vendor
Published estimates run from three weeks to twelve months per accounting system, and the work does not carry over from one vendor to the next. Here are the figures, their sources, and the alternative.
A platform that connects to its customers' accounting systems builds one integration per vendor. Published estimates for one integration run from three to four weeks for a first working QuickBooks connection to six to twelve months for NetSuite, and every estimate we found comes from a company that sells a way to avoid the work. The work does not carry over: QuickBooks, Xero, NetSuite and Microsoft Dynamics 365 Business Central each have their own sign-in method, token lifetimes, query syntax, rate limits, fees and deprecation schedule. Six vendors means six projects and six maintenance budgets.
This article collects the published figures with their sources, shows where the vendors differ, and explains the other option: keeping the books inside your own product through one accounting API, so there is one integration to build instead of one per vendor.
How long one accounting integration takes
Nobody publishes a neutral survey of integration build time. The figures below all come from companies that sell unified accounting APIs, so they have a reason to make the work look large. They are still the most specific numbers available, and they are consistent with each other once you separate "first working version" from "production".
| Source | What they say | Their stake |
|---|---|---|
| Apideck (2026) | QuickBooks: "a capable engineer can have something working in three to four weeks". Maintaining 35+ connectors needs "at minimum, one engineer dedicated to integration maintenance". | Sells a unified API |
| Rutter (April 2026) | "Three engineering-months per platform", which Rutter calls conservative. For NetSuite "the timeline stretches to six to twelve months". A customer estimated QuickBooks at two engineers for a couple of months; it took "at least three months with multiple iterations". | Sells a unified API |
| Merge | 150 hours to build one integration and 300 hours a year to maintain it, at a $150,000 salary. Merge puts the cost at "$50,000 to $150,000 per year". | Sells a unified API |
Two things in these numbers matter more than the totals.
First, the gap between three weeks and three months is the gap between a demo and production. A connection that creates an invoice works quickly. A connection that survives token expiry, duplicate webhooks, rate limits, partial failures and a customer who reconnects a different company file takes the rest of the time. Our guide to integrating a cloud accounting API into a SaaS platform lists that work step by step.
Second, maintenance is larger than the build in Merge's model: 300 hours a year against 150 hours once. That cost repeats every year for every vendor you support.
Why the second integration costs as much as the first
If the vendors exposed the same interface, the second integration would reuse most of the first. They do not. The table compares four widely used systems.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Sign-in | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; token-based authentication closed to new integrations from release 2027.1 | Microsoft Entra ID OAuth only |
| Access token lifetime | 1 hour | 30 minutes | 60 minutes | Set by Entra ID |
| Refresh token | 100 days rolling, at most five years | 60 days rolling | 7 days | Set by Entra ID |
| Query style | SQL-like SELECT … FROM Invoice, no OR, no joins |
REST with a where parameter |
SuiteQL (SQL) over REST, plus SOAP until 2028 | OData v4 |
| Rate limit | 500 requests a minute and 10 a second per company | 60 a minute, 5,000 a day and 5 concurrent per company | 5 to 20 concurrent requests per account, by service tier | 6,000 requests per 5 minutes and 5 concurrent per user |
| Separate API fee | App Partner Program: free tier, then US$300 to US$4,500 a month | App plans from free to AUD 1,445 a month | None found; extra concurrency is sold as SuiteCloud Plus licences | None found |
Sources: Intuit authorization FAQ, Intuit limits and throttles, Intuit App Partner Program guide, Xero OAuth 2.0 guide, Xero API limits, Xero pricing, NetSuite OAuth 2.0 tokens, NetSuite token-based authentication, Business Central operational limits.
Tokens expire on four different schedules
An integration has to refresh each vendor's tokens before they expire and store the new refresh token every time, or the customer has to connect again. The schedules differ by a factor of fourteen: a NetSuite refresh token lasts seven days, a QuickBooks one 100 days. QuickBooks adds a hard cap: refresh tokens are valid for at most five years, so long-running connections will start expiring on a fixed date regardless of use. Each schedule needs its own refresh job, its own failure handling and its own "please reconnect" message to the customer.
Each vendor has its own query language
Reading data back is where the code diverges most. QuickBooks accepts a restricted SQL dialect without OR and without joins, returning at most 1,000 records per page. Xero filters with a where expression in the URL and advises simple equality tests for large organisations. NetSuite has SuiteQL, a full SQL dialect posted to its own endpoint. Business Central uses OData filters. A query that finds unpaid invoices for one customer is four different pieces of code, each with its own paging and its own edge cases.
Each vendor limits traffic differently
QuickBooks and Xero count requests per company per minute. NetSuite counts concurrent requests across the whole account, so your integration shares a budget with every other integration the customer runs, and NetSuite rejects calls above the limit. Business Central counts per user over a five-minute window. A bulk import that is safe against one vendor gets throttled by another, so throttling and retry logic is written once per vendor.
Access is a commercial relationship
Two of the four vendors now charge for API access by volume. Intuit's App Partner Program meters "CorePlus" calls, which cover most data reads, and blocks them above the included amount on the free tier; the paid tiers cost US$300, US$1,700 and US$4,500 a month. Xero moved to paid app plans on 2 March 2026, from a free plan limited to 5 connections up to AUD 1,445 a month for 10,000 connections. The integration's running cost therefore depends on how many of your customers use each vendor and how much data you read.
The vendors change the rules on their own schedule
An integration that works today has a known list of forced rewrites already announced:
- NetSuite stops accepting new integrations that use token-based authentication from release 2027.1, and Oracle's SOAP notice says that "with the 2028.2 NetSuite release, all endpoints will be disabled, and SOAP-based integrations will stop working" (NetSuite SOAP notice).
- Xero assigns granular permission scopes to apps created from March 2026 and gives existing apps until September 2027 to move (Xero OAuth 2.0 overview).
- QuickBooks applies the five-year refresh-token cap described above, and retired older API minor versions so that version 75 is the base.
- Business Central online stopped accepting access keys (basic authentication) for web services in 2022; integrations had to move to Entra ID OAuth (Microsoft deprecation list).
None of these changes add a feature for your customers. Each one is engineering time spent to keep an existing connection working, multiplied by the number of vendors you support.
The arithmetic for six integrations
Take Rutter's figure of three engineering-months per platform and Merge's figure of 300 maintenance hours a year, and apply them to six accounting systems:
| One vendor | Six vendors | |
|---|---|---|
| Build | 3 engineering-months | 18 engineering-months |
| Maintenance per year | 300 hours | 1,800 hours, close to one full-time engineer |
These are the vendors' own assumptions, not ours, and NetSuite alone would exceed them. The point is the shape: the cost grows with the number of vendors, and the maintenance line never ends. A unified API reduces the build line, but you then depend on how well it covers each vendor's writes and edge cases, and you pay for it per connection or per call. Our build-versus-buy article walks through costing this honestly.
Integrate once: keep the books in your product
The connector model assumes each customer's books live in a system the customer chose, and your platform copies data into it. There is a second model: your platform keeps the books itself, through one accounting API, and shows them in your own interface. That is what Nordlet is built for. There is one integration to build, whatever accounting software your customers used before.
What that one integration looks like in Nordlet:
- One request shape. Every operation is
POST /v1/{module}/{resource}/{action}. Everylistaction accepts the same filter, sort and paging body, and every error uses the same envelope. Code written for one endpoint works the same way for the others. See API conventions. - API keys instead of refresh tokens. A key belongs to one company, carries fixed permission scopes, can have an expiry date you set, and can be revoked. There is no refresh token to rotate and store.
- Safe retries. Every change accepts an
Idempotency-Keyheader. Repeating a request with the same key returns the stored response instead of creating a second invoice. - Signed webhooks with retries. Events are written in the same database transaction as the change, signed with HMAC-SHA256, and retried for about 24 hours.
- One published rate limit. 300 requests a minute per API key, reported in
x-ratelimit-*headers. - Typed SDKs in nine languages, generated from one OpenAPI specification. See SDKs.
- Unlimited sandbox companies under one account for integration testing.
- One price list. Plans are metered by request, from €10 a month for 3,000 requests. See pricing.
The double-entry ledger, invoices, bank matching, VAT returns and reports are available through that same API, so the integration covers the accounting itself rather than a copy of it. The features page lists what is included, and what an accounting API is explains the model in more detail.
Customers who already have books elsewhere
Two things replace the per-vendor connectors that a platform would otherwise build for these customers:
- Moving in. A company's chart of accounts, partners, opening balances or full journal history, open invoices, fixed assets and stock are imported in one call. See migrating from another system.
- Files for the accountant. Where a customer's accountant works in their own software, Nordlet exports the ledger in the formats that software reads: a DATEV booking batch (
POST /v1/reports/datev) for German accountants and an SIE 4 file (POST /v1/reports/sie) for Swedish ones. A file export needs no sign-in, no token refresh and no per-call fee from the accounting vendor.
When connectors are still the right answer
Keeping the books in your product is not the right choice for every platform:
- If your customers' finance teams require their existing accounting system to remain the system of record, you need connectors to that system, either built directly or through a unified API.
- If you only need to push a few documents into the customer's books, such as one invoice per order, one direct connector to the vendor most of your customers use may be enough.
- If most of your customers use one vendor, a single direct integration costs one project, not six.
The integrate-once argument applies when your platform needs to run its users' accounting, not mirror it: marketplaces paying out to sellers, platforms invoicing on behalf of their users, and SaaS products where bookkeeping is part of the product. Before choosing either path, our pre-production test plan for an accounting API lists what to test.
FAQ
How long does it take to build a QuickBooks integration?
Apideck estimates three to four weeks for a first working version by one capable engineer. A Rutter customer estimated two engineers for a couple of months and needed at least three months with several iterations. Production work - token refresh, retries, rate limits, reconnection and reconciliation - is the difference between those figures.
How long does a NetSuite integration take?
Rutter puts NetSuite at six to twelve months. NetSuite adds account-wide concurrency limits, seven-day refresh tokens, SuiteQL alongside SOAP, and announced changes: no new token-based-authentication integrations from release 2027.1 and SOAP endpoints disabled in release 2028.2.
Does a unified accounting API remove the per-vendor work?
It reduces the build, because one interface covers several vendors. It does not remove vendor differences: writes, custom fields and edge cases are often supported unevenly, and the unified API's pricing is added to the vendors' own API fees. The trade-offs are covered in our SaaS integration guide.
How much does API access to QuickBooks and Xero cost?
Intuit's App Partner Program has a free Builder tier and paid tiers at US$300, US$1,700 and US$4,500 a month, with data reads metered above an included amount. Xero's app plans, in effect since 2 March 2026, run from a free plan for 5 connections to AUD 1,445 a month for 10,000 connections, with larger plans priced on application.
Can Nordlet replace integrations with my customers' accounting systems?
When your platform keeps its users' books, yes: you build one integration with Nordlet's API instead of one per accounting vendor. Existing books are imported in one call, and accountants who use DATEV or SIE-compatible software receive export files. Nordlet does not sync into QuickBooks, Xero, NetSuite or Business Central; if those must stay the system of record, you still need connectors to them.