Kostnad för bokföringsintegration: Ett projekt per leverantör
Publicerade uppskattningar sträcker sig från tre veckor till tolv månader per bokföringssystem, och arbetet kan inte återanvändas från en leverantör till nästa. Här är siffrorna, deras källor och alternativet.
En plattform som ansluter till sina kunders bokföringssystem bygger en integration per leverantör. Publicerade uppskattningar för en enda integration sträcker sig från tre till fyra veckor för en första fungerande QuickBooks-anslutning till sex till tolv månader för NetSuite, och varje uppskattning vi hittat kommer från ett företag som säljer ett sätt att slippa arbetet. Arbetet går inte att återanvända: QuickBooks, Xero, NetSuite och Microsoft Dynamics 365 Business Central har alla egna inloggningsmetoder, tokenlivslängder, frågespråk, hastighetsbegränsningar, avgifter och livscykler. Sex leverantörer innebär sex projekt och sex underhållsbudgetar.
Den här artikeln samlar de publicerade siffrorna med tillhörande källor, visar var leverantörerna skiljer sig åt och förklarar det andra alternativet: att sköta bokföringen direkt i din egen produkt via ett enda bokförings-API, vilket gör att du bara behöver bygga en integration i stället för en per leverantör.
Hur lång tid en bokföringsintegration tar
Ingen publicerar en neutral undersökning av utvecklingstiden för integrationer. Siffrorna nedan kommer uteslutande från företag som säljer enhetliga bokförings-API:er (unified accounting APIs), vilket innebär att de har incitament att få arbetet att framstå som omfattande. De är ändå de mest specifika siffror som finns att tillgå, och de är konsekventa med varandra så fort man skiljer på en ”första fungerande version” och ”produktion”.
| Källa | Vad de säger | Deras intresse |
|---|---|---|
| Apideck (2026) | QuickBooks: ”en skicklig utvecklare kan få något att fungera på tre till fyra veckor”. Att underhålla fler än 35 kopplingar kräver ”minst en utvecklare som uteslutande ägnar sig åt underhåll av integrationer”. | Säljer ett enhetligt API |
| Rutter (april 2026) | ”Tre utvecklarmånader per plattform”, vilket Rutter kallar konservativt. För NetSuite ”sträcker sig tidsplanen till sex till tolv månader”. En kund uppskattade QuickBooks till två utvecklare under ett par månader; det tog ”minst tre månader med flera iterationer”. | Säljer ett enhetligt API |
| Merge | 150 timmar för att bygga en integration och 300 timmar om året för att underhålla den, baserat på en lön på 150 000 USD. Merge anger kostnaden till ”50 000 till 150 000 USD per år”. | Säljer ett enhetligt API |
Två saker i dessa siffror är viktigare än totalsummorna.
För det första är glappet mellan tre veckor och tre månader skillnaden mellan en demo och en produktionsmiljö. En anslutning som skapar en faktura går snabbt att få på plats. En anslutning som klarar utgångna tokens, dubblett-webhooks, hastighetsbegränsningar, partiella fel och en kund som återansluter en annan företagsfil tar resten av tiden. Vår guide till att integrera ett molnbaserat bokförings-API i en SaaS-plattform går igenom det arbetet steg för steg.
För det andra är underhållet mer omfattande än själva bygget i Merges modell: 300 timmar om året mot 150 timmar en gång för alla. Den kostnaden återkommer varje år för varje leverantör du stöder.
Varför den andra integrationen kostar lika mycket som den första
Om leverantörerna tillhandahöll samma gränssnitt skulle den andra integrationen återanvända det mesta från den första. Det gör de inte. Tabellen jämför fyra flitigt använda system.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Inloggning | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; tokenbaserad autentisering stängs för nya integrationer från version 2027.1 | Endast Microsoft Entra ID OAuth |
| Åtkomsttokenns livslängd | 1 timme | 30 minuter | 60 minuter | Bestäms av Entra ID |
| Uppdateringstoken (refresh token) | 100 dagars rullande fönster, maximalt fem år | 60 dagars rullande fönster | 7 dagar | Bestäms av Entra ID |
| Frågestil | SQL-liknande SELECT … FROM Invoice, saknar OR, saknar joins |
REST med en where-parameter |
SuiteQL (SQL) över REST, samt SOAP fram till 2028 | OData v4 |
| Hastighetsbegränsning | 500 anrop per minut och 10 per sekund per företag | 60 per minut, 5 000 om dagen och 5 samtidiga per företag | 5 till 20 samtidiga anrop per konto, beroende på tjänstenivå | 6 000 anrop per 5 minuter och 5 samtidiga per användare |
| Separat API-avgift | App Partner Program: gratisnivå, därefter 300 till 4 500 USD per månad | App-abonnemang från gratis till 1 445 AUD per månad | Ej funnen; extra samtidighet säljs som SuiteCloud Plus-licenser | Ej funnen |
Källor: 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 löper ut enligt fyra olika tidscheman
En integration måste uppdatera varje leverantörs tokens innan de löper ut och lagra den nya uppdateringstoken varje gång, annars tvingas kunden att ansluta på nytt. Scheman skiljer sig åt med en faktor på fjorton: en uppdateringstoken för NetSuite varar i sju dagar, medan en för QuickBooks varar i 100 dagar. QuickBooks har dessutom en hård gräns: uppdateringstokens är giltiga i högst fem år, vilket innebär att långlivade anslutningar börjar löpa ut på ett fast datum oavsett användning. Varje schema kräver sitt eget bakgrundsjobb för uppdatering, sin egen felhantering och sitt eget meddelande till kunden om att ”ansluta på nytt”.
Varje leverantör har sitt eget frågespråk
Det är vid inläsning av data som koden skiljer sig mest åt. QuickBooks accepterar en begränsad SQL-dialekt utan OR och utan joins, och returnerar som mest 1 000 poster per sida. Xero filtrerar med ett where-uttryck i URL:en och rekommenderar enkla likhetstester för stora organisationer. NetSuite har SuiteQL, en fullständig SQL-dialekt som skickas till dess egen endpoint. Business Central använder OData-filter. En sökning som letar upp obetalda fakturor för en kund blir därmed fyra helt skilda kodstycken, vart och ett med sin egen paginering och sina egna specialfall.
Varje leverantör begränsar trafik på olika sätt
QuickBooks och Xero räknar anrop per företag och minut. NetSuite räknar samtidiga anrop för hela kontot, vilket gör att din integration delar utrymme med alla andra integrationer som kunden kör, och NetSuite avvisar anrop som överskrider gränsen. Business Central räknar per användare under ett fönster på fem minuter. En massimport som fungerar smidigt mot en leverantör blir strypt av en annan, vilket innebär att strypnings- och återförsökslogik (retry logic) måste skrivas om för varje enskild leverantör.
Åtkomst är en affärsrelation
Två av de fyra leverantörerna tar numera betalt för API-åtkomst baserat på volym. Intuits App Partner Program mäter så kallade CorePlus-anrop, som täcker de flesta datainläsningar, och blockerar dem om de överstiger den kvantitet som ingår på gratisnivån; betalnivåerna kostar 300, 1 700 respektive 4 500 USD per månad. Xero gick över till betalda app-abonnemang den 2 mars 2026, från en gratisplan begränsad till 5 anslutningar upp till 1 445 AUD i månaden för 10 000 anslutningar. Integrationens löpande kostnad beror därmed på hur många av dina kunder som använder respektive leverantör och hur mycket data du läser in.
Leverantörerna ändrar reglerna på egen hand
En integration som fungerar i dag har redan en känd lista över tvingande omskrivningar framför sig:
- NetSuite slutar acceptera nya integrationer som använder tokenbaserad autentisering från och med version 2027.1, och Oracles meddelande om SOAP anger att ”i och med NetSuite-version 2028.2 kommer alla endpoints att stängas av, och SOAP-baserade integrationer slutar fungera” (NetSuite SOAP notice).
- Xero inför detaljerade behörighetsomfång (permission scopes) för appar som skapas från och med mars 2026 och ger befintliga appar till september 2027 på sig att ställa om (Xero OAuth 2.0 overview).
- QuickBooks tillämpar det ovan nämnda femåriga taket för uppdateringstokens och har fasat ut äldre mindre API-versioner så att version 75 utgör grunden.
- Business Central online slutade acceptera åtkomstnycklar (enkel autentisering, basic authentication) för webbtjänster under 2022; integrationer var tvungna att gå över till Entra ID OAuth (Microsoft deprecation list).
Ingen av dessa förändringar tillför någon ny funktion för dina kunder. Varje åtgärd motsvarar ren utvecklingstid som krävs enbart för att hålla en befintlig anslutning vid liv, multiplicerat med antalet leverantörer du stöder.
Matematiken bakom sex integrationer
Om vi utgår från Rutters uppskattning om tre utvecklarmånader per plattform och Merges siffra om 300 underhållstimmar om året, och tillämpar detta på sex bokföringssystem, ser kalkylen ut så här:
| En leverantör | Sex leverantörer | |
|---|---|---|
| Bygge | 3 utvecklarmånader | 18 utvecklarmånader |
| Underhåll per år | 300 timmar | 1 800 timmar, nära på en heltidstjänst för en utvecklare |
Detta bygger på leverantörernas egna antaganden, inte våra, och enbart NetSuite skulle överstiga dem. Poängen ligger i kurvans form: kostnaden växer i takt med antalet leverantörer, och underhållsposten tar aldrig slut. Ett enhetligt API minskar byggtiden, men du blir då beroende av hur väl det täcker varje leverantörs skrivningar och specialfall, och du betalar för det per anslutning eller per anrop. Vår artikel om att bygga kontra köpa går igenom hur man räknar på detta på ett ärligt sätt.
Integrera en gång: ha bokföringen i din produkt
Kopplingsmodellen bygger på antagandet att varje kunds bokföring finns i ett system som kunden själv har valt, och att din plattform kopierar data dit. Det finns en andra modell: din plattform sköter bokföringen själv via ett enda bokförings-API och visar den i ett eget gränssnitt. Det är precis det som Nordlet är byggt för. Det finns bara en integration att bygga, oavsett vilken bokföringsprogramvara dina kunder använde tidigare.
Så här ser den enda integrationen ut i Nordlet:
- Ett anropsformat. Varje åtgärd är
POST /v1/{module}/{resource}/{action}. Varjelist-åtgärd accepterar samma filter-, sorterings- och pagineringsstruktur, och varje felmeddelande använder samma formatering. Kod som skrivits för en endpoint fungerar på samma sätt för de andra. Se API-konventioner. - API-nycklar i stället för uppdateringstokens. En nyckel tillhör ett företag, har fastställda behörighetsomfång, kan ges ett eget utgångsdatum och kan spärras. Det finns ingen uppdateringstoken som behöver roteras och lagras.
- Säkra återförsök. Varje ändring accepterar en
Idempotency-Key-header. Om samma anrop skickas igen med samma nyckel returneras det sparade svaret i stället för att en andra faktura skapas. - Signerade webhooks med återförsök. Händelser skrivs i samma databastransaktion som ändringen, signeras med HMAC-SHA256 och skickas på nytt vid behov i cirka 24 timmar.
- En enda publicerad hastighetsbegränsning. 300 anrop per minut och API-nyckel, vilket rapporteras via
x-ratelimit-*-headers. - Typade SDK:er på nio språk, genererade utifrån en enda OpenAPI-specifikation. Se SDK:er.
- Obegränsat antal sandlådeföretag under ett och samma konto för integrationstestning.
- En enda prislista. Abonnemangen baseras på antal anrop, från 10 EUR i månaden för 3 000 anrop. Se priser.
Dubbel bokföring, fakturor, bankavstämning, momsdeklarationer och rapporter nås genom samma API, vilket gör att integrationen täcker själva bokföringen i stället för att bara spegla den. Funktionssidan listar vad som ingår, och vad ett bokförings-API är förklarar modellen mer i detalj.
Kunderna som redan har sin bokföring någon annanstans
Två funktioner ersätter de leverantörsspecifika kopplingar som en plattform annars skulle behöva bygga för dessa kunder:
- Flytten in. Ett företags kontoplan, affärspartner, ingående balanser eller fullständiga journalhistorik, öppna fakturor, anläggningstillgångar och lager importeras i ett enda anrop. Se migrering från ett annat system.
- Filer för redovisningskonsulten. I de fall kundens konsult arbetar i ett eget program exporterar Nordlet huvudboken i de format som programvaran läser: en DATEV-bokföringsbatch (
POST /v1/reports/datev) för tyska konsulter och en SIE 4-fil (POST /v1/reports/sie) för svenska. En filexport kräver varken inloggning, tokenförnyelse eller per-anrop-avgift från bokföringsleverantören.
När kopplingar fortfarande är rätt svar
Att ha bokföringen i din produkt är inte rätt val för varje plattform:
- Om dina kunders ekonomiavdelningar kräver att deras befintliga bokföringssystem förblir det registerhållande systemet (system of record), behöver du kopplingar till det systemet, antingen byggda direkt eller via ett enhetligt API.
- Om du bara behöver skicka ett fåtal dokument till kundens bokföring, till exempel en faktura per beställning, kan en direktkoppling till den leverantör de flesta av dina kunder använder räcka långt.
- Om de flesta av dina kunder använder samma leverantör kostar en enda direktintegration ett projekt i stället för sex.
Argumentet om att integrera en gång gäller när din plattform behöver köra sina användares bokföring i stället för att spegla den: marknadsplatser som betalar ut pengar till säljare, plattformar som fakturerar för sina användares räkning och SaaS-produkter där bokföring utgör en del av produkten. Innan du väljer väg går vår testplan före produktion för ett bokförings-API igenom vad som behöver testas.
FAQ
Hur lång tid tar det att bygga en QuickBooks-integration?
Apideck uppskattar tre till fyra veckor för en första fungerande version utförd av en skicklig utvecklare. En Rutter-kund uppskattade två utvecklare under ett par månader och behövde minst tre månader med flera iterationer. Produktionsarbete – uppdatering av tokens, återförsök, hastighetsbegränsningar, återanslutning och avstämning – är skillnaden mellan de siffrorna.
Hur lång tid tar en NetSuite-integration?
Rutter anger att NetSuite tar sex till tolv månader. NetSuite tillför kontogräffar för samtidiga anrop, sju dagars uppdateringstokens, SuiteQL vid sidan av SOAP samt aviserade förändringar: inga nya integrationer med tokenbaserad autentisering från version 2027.1 och SOAP-endpoints som inaktiveras i version 2028.2.
Tar ett enhetligt bokförings-API bort det leverantörsspecifika arbetet?
Det minskar byggtiden eftersom ett enda gränssnitt täcker flera leverantörer. Det tar inte bort leverantörsskillnaderna: skrivningar, anpassade fält och specialfall stöds ofta ojämnt, och det enhetliga API:ets prissättning läggs ovanpå leverantörernas egna API-avgifter. Avvägningarna tas upp i vår SaaS-integrationsguide.
Hur mycket kostar API-åtkomst till QuickBooks och Xero?
Intuits App Partner Program har en kostnadsfri Builder-nivå och betalnivåer på 300, 1 700 respektive 4 500 USD i månaden, där datainläsningar mäts överstigande en ingående kvantitet. Xeros app-abonnemang, som gäller sedan den 2 mars 2026, sträcker sig från en gratisplan för 5 anslutningar till 1 445 AUD i månaden för 10 000 anslutningar, medan större abonnemang prissätts på begäran.
Kan Nordlet ersätta integrationer med mina kunders bokföringssystem?
När din plattform sköter användarnas bokföring, ja: du bygger en integration med Nordlets API i stället för en per bokföringsleverantör. Befintlig bokföring importeras i ett enda anrop, och konsulter som använder DATEV- eller SIE-kompatibel programvara får exportfiler. Nordlet synkroniserar inte till QuickBooks, Xero, NetSuite eller Business Central; om dessa måste förbli registerhållande system behöver du fortfarande kopplingar dit.