Kostnad for regnskapsintegrasjon: Ett prosjekt per leverandør
Publiserede estimater spenner fra tre uker til tolv måneder per regnskapssystem, og arbeidet kan ikke overføres fra én leverandør til den neste. Her er tallene, kildene deres og alternativet.
En plattform som kobler seg til kundenes regnskapssystemer, bygger én integrasjon per leverandør. Publiserte anslag for én enkelt integrasjon varierer fra tre til fire uker for en første fungerende QuickBooks-tilkobling til seks til tolv måneder for NetSuite, og hvert eneste anslag vi har funnet kommer fra et selskap som selger en måte å slippe unna dette arbeidet på. Arbeidet kan ikke gjenbrukes: QuickBooks, Xero, NetSuite og Microsoft Dynamics 365 Business Central har hver sin påloggingsmetode, token-levetid, spørringssyntaks, hastighetsbegrensninger (rate limits), gebyrer og utfasingstidsplan. Seks leverandører betyr seks prosjekter og seks budsjetter for vedlikehold.
Denne artikkelen samler de publiserte tallene med kildene sine, viser hvor leverandørene skiller seg fra hverandre, og forklarer det andre alternativet: å holde regnskapet inne i ditt eget produkt gjennom ett enkelt regnskaps-API, slik at du bare har én integrasjon å bygge i stedet for én per leverandør.
Hvor lang tid en regnskapsintegrasjon tar
Ingen publiserer en nøytral undersøkelse av hvor lang tid det tar å bygge integrasjoner. Tallene nedenfor kommer fra selskaper som selger enhetlige regnskaps-API-er (unified accounting APIs), så de har en interesse av å få arbeidet til å fremstå som omfattende. Likevel er dette de mest spesifikke tallene som er tilgjengelige, og de henger godt sammen så snart man skiller mellom en første fungerende versjon og en produksjonsklar løsning.
| Kilde | Hva de sier | Deres motiv |
|---|---|---|
| Apideck (2026) | QuickBooks: "en dyktig utvikler kan ha noe oppe og gå på tre til fire uker". Å vedlikeholde 35+ koblinger krever "minst én utvikler dedikert til integrasjonsvedlikehold". | Selger et enhetlig API |
| Rutter (april 2026) | "Tre utviklermåneder per plattform", noe Rutter kaller konservativt. For NetSuite "strekker tidslinjen seg til seks til tolv måneder". En kunde anslo QuickBooks til to utviklere i eit par måneder; det tok "minst tre måneder med flere runder med iterasjoner". | Selger et enhetlig API |
| Merge | 150 timer for å bygge én integrasjon og 300 timer i året på å vedlikeholde den, basert på en lønn på 150 000 USD. Merge anslår kostnaden til "50 000 til 150 000 USD per år". | Selger et enhetlig API |
To ting ved disse tallene er viktigere enn totalsummene.
For det første er gapet mellom tre uker og tre måneder avstanden mellom en demo og et produksjonssystem. En tilkobling som oppretter en faktura, fungerer raskt. Resten av tiden går med til å lage en tilkobling som tåler at tokens utløper, doble webhooks, hastighetsbegrensninger, delvis feilede kall og en kunde som kobler til en annen selskapsfil. Vår guide til integrering av et skybasert regnskaps-API i en SaaS-plattform lister opp dette arbeidet steg for steg.
For det andre er vedlikehold mer tidkrevende enn selve byggingen i Merges modell: 300 timer i året mot 150 timer én enkelt gang. Den kostnaden gjentas hvert eneste år for hver leverandør du støtter.
Hvorfor den andre integrasjonen koster like mye som den første
Hvis leverandørene tilbød det samme grensesnittet, kunne den andre integrasjonen gjenbrukt det meste fra den første. Det gjør de ikke. Tabellen sammenligner fire mye brukte systemer.
| QuickBooks Online | Xero | NetSuite | Business Central | |
|---|---|---|---|---|
| Pålogging | OAuth 2.0 | OAuth 2.0 | OAuth 2.0; token-basert autentisering stenges for nye integrasjoner fra versjon 2027.1 | Kun Microsoft Entra ID OAuth |
| Levetid for accesstoken | 1 time | 30 minutter | 60 minutter | Angis av Entra ID |
| Refresh-token | 100 dagers rullerende gyldighet, maks fem år | 60 dagers rullerende gyldighet | 7 dager | Angis av Entra ID |
| Spørringsstil | SQL-lignende SELECT … FROM Invoice, ingen OR, ingen joins |
REST med et where-parameter |
SuiteQL (SQL) over REST, i tillegg til SOAP frem til 2028 | OData v4 |
| Hastighetsbegrensning (Rate limit) | 500 forespørsler i minuttet og 10 i sekundet per selskap | 60 i minuttet, 5 000 om dagen og 5 samtidige per selskap | 5 til 20 samtidige forespørsler per konto, avhengig av tjenestenivå | 6 000 forespørsler per 5 minutter og 5 samtidige per bruker |
| Separat API-gebyr | App Partner Program: gratisnivå, deretter 300 til 4 500 USD per måned | App-abonnementer fra gratis til 1 445 AUD per måned | Ikke funnet; ekstra samtidig kapasitet selges som SuiteCloud Plus-lisenser | Ikke funnet |
Kilder: 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 utløper etter fire ulike tidsplaner
En integrasjon må fornye hver leverandørs tokens før de utløper, og lagre det nye refresh-tokenet hver eneste gang, ellers må kunden koble seg til på nytt. Tidsplanene varierer med en faktor på fjorten: et NetSuite refresh-token varer i sju dager, mens et fra QuickBooks varer i 100 dager. QuickBooks har i tillegg en absolutt grense: refresh-tokens er gyldige i maksimalt fem år, slik at langvarige tilkoblinger vil begynne å utløpe på en fast dato uavhengig av bruk. Hver tidsplan krever sin egen bakgrunnsjobb for fornyelse, sin egen feilhantering og sin egen «vennligst koble til på nytt»-melding til kunden.
Hver leverandør har sitt eget spørrespråk
Det er ved henting av data at koden spriker mest. QuickBooks aksepterer en begrenset SQL-dialekt uten OR og uten joins, og returnerer maks 1 000 rader per side. Xero filtrerer med et where-uttrykk i URL-en og anbefaler enkle likhetstester for store organisasjoner. NetSuite bruker SuiteQL, en fullverdig SQL-dialekt som sendes til sitt eget endepunkt. Business Central bruker OData-filtre. En forespørsel som henter ubetalte fakturaer for én kunde, blir dermed fire ulike kodesnutter, hver med sin egen paginering og sine egne særegenheter.
Hver leverandør begrenser trafikken på ulike måter
QuickBooks og Xero teller forespørsler per selskapsfil i minuttet. NetSuite teller samtidige forespørsler på tvers av hele kontoen, slik at integrasjonen din deler kvote med alle andre integrasjoner kunden kjører, og NetSuite avviser kall som går over grensen. Business Central teller per bruker over et vindu på fem minutter. En massiv import som går knirkefritt hos én leverandør, blir stoppet av en annen, noe som betyr at du må skrive egen logikk for struping (throttling) og nye forsøk for hver enkelt leverandør.
Tilgang er et kommersielt forhold
To av de fire leverandørene tar nå betalt for API-tilgang basert på volum. Intuits App Partner Program måler "CorePlus"-kall, som dekker de fleste leseforespørsler, og blokkerer dem dersom de overstiger den inkluderte mengden på gratisnivået. Betalte nivåer koster 300, 1 700 og 4 500 USD i måneden. Xero gikk over til betalte app-abonnementer den 2. mars 2026, fra en gratisplan begrenset til 5 tilkoblinger og opp til 1 445 AUD i måneden for 10 000 tilkoblinger. Løpende kostnader for integrasjonen avhenger dermed av hvor mange av kundene dine som bruker de ulike leverandørene, og hvor mye data du leser.
Leverandørene endrer reglene etter sin egen tidsplan
En integrasjon som fungerer i dag, har allerede en kjent liste over påtvunget omskriving i vente:
- NetSuite slutter å godta nye integrasjoner som bruker token-basert autentisering fra versjon 2027.1, og Oracles SOAP-varsel slår fast at "med NetSuite-versjon 2028.2 vil alle endepunkter bli deaktivert, og SOAP-baserte integrasjoner vil slutte å virke" (NetSuite SOAP notice).
- Xero innfører mer granulære tillatelsesskaper (permission scopes) for apper opprettet fra og med mars 2026, og gir eksisterende apper frist til september 2027 med å oppdatere seg (Xero OAuth 2.0 overview).
- QuickBooks innfører den nevnte femårsgrensen for refresh-tokens, og har pensjonert eldre API-versjoner slik at versjon 75 nå er minimum.
- Business Central online sluttet å godta tilgangsnøkler (grunnleggende autentisering / basic auth) for webtjenester i 2022; integrasjoner måtte flytte over til Entra ID OAuth (Microsoft deprecation list).
Ingen av disse endringene tilføyer ny funksjonalitet for kundene dine. Hver enkelt representerer utviklertid som går med til å holde en eksisterende tilkobling i gang, multiplisert med antall leverandører du støtter.
Regnestykket for seks integrasjoner
Ta Rutters anslag på tre utviklermåneder per plattform og Merges anslag på 300 vedlikeholdstimer i året, og bruk det på seks regnskapssystemer:
| Én leverandør | Seks leverandører | |
|---|---|---|
| Bygging | 3 utviklermåneder | 18 utviklermåneder |
| Vedlikehold per år | 300 timer | 1 800 timer, tilsvarende nesten én fulltidsutvikler |
Dette er leverandørene sine egne forutsetninger, ikke våre, og NetSuite alene vil overstige disse tallene. Poenget ligger i formen: kostnaden vokser i takt med antall leverandører, og vedlikeholdsposten tar aldri slutt. Et enhetlig API reduserer byggetiden, men da blir du avhengig av hvor godt det dekker hver enkelt leverandørs skriveoperasjoner og særtilfeller, og du betaler for det per tilkobling eller per kall. Artikkelen vår om bygging versus kjøp av integrasjoner går grundig gjennom hvordan du regner på dette på en ærlig måte.
Integrer én gang: ha regnskapet i produktet ditt
Koblingsmodellen (connector model) baserer seg på at hver kundes regnskap ligger i et system kunden selv har valgt, og at plattformen din kopierer data inn i det. Det finnes en annen modell: plattformen din fører regnskapet selv, gjennom ett enkelt regnskaps-API, og viser det i ditt eget grensesnitt. Det er dette Nordlet er bygget for. Du har én integrasjon å bygge, uavhengig av hvilken regnskapsprogramvare kundene dine brukte før.
Slik ser den ene integrasjonen ut i Nordlet:
- Ett felles format for forespørsler. Hver operasjon er en
POST /v1/{module}/{resource}/{action}. Allelist-handlinger aksepterer det samme filter-, sorterings- og pagineringsformatet, og alle feilmeldinger bruker den samme innpakningen. Kode som er skrevet for ett endepunkt, fungerer på samme måte for de andre. Se API-konvensjoner. - API-nøkler i stedet for refresh-tokens. En nøkkel tilhører ett selskap, har faste tillatelsesnivåer, kan få en utløpsdato du selv setter, og kan trekkes tilbake. Det er ingen refresh-tokens som må rulleres og lagres.
- Trygge nye forsøk (Safe retries). Alle endringer godtar en
Idempotency-Key-header. Hvis du gjentar en forespørsel med samme nøkkel, returneres den lagrede responsen i stedet for å opprette en faktura nummer to. - Signerte webhooks med nye forsøk. Hendelser skrives i den samme databasetransaksjonen som endringen, signeres med HMAC-SHA256, og forsøkes sendt på nytt i omtrent 24 timer.
- Én fastsatt hastighetsbegrensning. 300 forespørsler i minuttet per API-nøkkel, som rapporteres i
x-ratelimit-*-headere. - Typebestemte SDK-er på ni språk, generert fra én enkelt OpenAPI-spesifikasjon. Se SDK-er.
- Ubegrenset med sandkasseselskaper under én konto for integrasjonstesting.
- Én prisliste. Planer belastes etter bruk basert på forespørsler, fra 10 euro i måneden for 3 000 forespørsler. Se priser.
Hovedbok med doble bokføringsprinsipper (double-entry ledger), fakturaer, bankavstemming, mva-meldinger og rapporter er tilgjengelig gjennom det samme API-et, slik at integrasjonen dekker selve regnskapet i stedet for bare en kopi av det. Funksjonssiden lister opp hva som er inkludert, og hva et regnskaps-API er forklarer modellen mer detaljert.
Kunder som allerede har regnskapet et annet sted
To funksjoner erstatter koblingene per leverandør som en plattform ellers måtte ha bygd for disse kundene:
- Flytte inn. En bedrifts kontoplan, partnere, åpningsbalanser eller fulle transaksjonshistorikk, åpne fakturaer, anleggsmidler og lager importeres i én enkelt operasjon. Se migrering fra et annet system.
- Filer for regnskapsføreren. Der kundens regnskapsfører jobber i sitt eget program, eksporterer Nordlet hovedboken i formater som det programmet leser: en DATEV-bokføringsbunt (
POST /v1/reports/datev) for tyske regnskapsførere og en SIE 4-fil (POST /v1/reports/sie) for svenske. En fileksport krever verken pålogging, token-fornyelse eller per-kall-gebyr fra regnskapsleverandøren.
Når integrasjonskoblinger fremdeles er det rette svaret
Å ha regnskapet inne i produktet ditt er ikke det rette valget for enhver plattform:
- Hvis kundenes økonomiavdelinger krever at deres eksisterende regnskapssystem forblir kilden til sanning (system of record), trenger du tilkoblinger til det systemet, enten bygget direkte eller gjennom et enhetlig API.
- Hvis du bare trenger å sende noen få dokumenter inn i kundens regnskap, for eksempel én faktura per ordre, kan én direkte tilkobling til leverandøren de fleste av kundene dine bruker, være tilstrekkelig.
- Hvis de fleste av kundene dine bruker én og samme leverandør, koster én enkelt direkte integrasjon ett prosjekt, ikke seks.
Argumentet for å integrere én gang gjelder når plattformen din skal kjøre brukernes regnskap, ikke speile det: markedsplasser som utbetaler penger til selgere, plattformer som fakturerer på vegne av brukerne sine, og SaaS-produkter der bokføring er en del av selve produktet. Før du velger vei, lister vår testplan før produksjon for et regnskaps-API opp hva du bør teste.
FAQ
Hvor lang tid tar det å bygge en QuickBooks-integrasjon?
Apideck anslår tre til fire uker for en første fungerende versjon utført av én dyktig utvikler. En Rutter-kunde anslo to utviklere i et par måneder og trengte minst tre måneder med flere runder med iterasjoner. Produksjonsarbeid – token-fornyelse, nye forsøk, hastighetsbegrensninger, gjenoppretting av tilkobling og avstemming – er det som skiller disse tallene fra hverandre.
Hvor lang tid tar en NetSuite-integrasjon?
Rutter anslår at NetSuite tar seks til tolv måneder. NetSuite har i tillegg begrensninger for samtidige kall på tvers av kontoen, 7-dagers refresh-tokens, SuiteQL ved siden av SOAP, og varslede endringer: ingen nye integrasjoner med token-basert autentisering fra versjon 2027.1, og SOAP-endepunkter deaktiveres i versjon 2028.2.
Fjerner et enhetlig regnskaps-API arbeidet per leverandør?
Det reduserer byggetiden, ettersom ett enkelt grensesnitt dekker flere leverandører. Det fjerner ikke forskjellene mellom leverandørene: skriveoperasjoner, egendefinerte felt (custom fields) og særtilfeller støttes ofte ujevnt, og det enhetlige API-ets pris kommer i tillegg til leverandørenes egne API-gebyrer. Avveiningene dekkes i vår SaaS-integrasjonsguide.
Hva koster API-tilgang til QuickBooks og Xero?
Intuits App Partner Program har et gratis Builder-nivå og betalte nivåer på 300, 1 700 og 4 500 USD i måneden, der datalesninger belastes utover en inkludert mengde. Xeros app-abonnementer, som gjelder fra 2. mars 2026, spenner fra en gratisplan for 5 tilkoblinger til 1 445 AUD i måneden for 10 000 tilkoblinger, der større planer prissettes etter forespørsel.
Kan Nordlet erstatte integrasjoner med kundenes regnskapssystemer?
Når plattformen din fører brukernes regnskap: Ja. Du bygger én integrasjon med Nordlets API i stedet for én per regnskapsleverandør. Eksisterende regnskap importeres i ett enkelt kall, og regnskapsførere som bruker DATEV- eller SIE-kompatibel programvare, mottar eksportfiler. Nordlet synkroniserer ikke inn i QuickBooks, Xero, NetSuite eller Business Central; dersom disse må forbli kilden til sanning, trenger du fremdeles koblinger til dem.