Alternativ till QuickBooks när du behöver ett API, inte en app

Varför plattformsteam växer ur QuickBooks, vad "API, inte en app" faktiskt kräver och vilka alternativ som passar för vilken uppgift.

QuickBooks Online är ett kompetent bokföringsprogram för småföretag med en stor användarbas, ett OAuth 2.0 REST API, webhooks och ett omfattande utvecklarekosystem. De flesta team som letar efter ett alternativ är inte missnöjda med det som applikation. De har stött på ett annat problem: de behöver programvara, inte en människa, för att sköta bokföringen, och QuickBooks är byggt utifrån antagandet att en människa gör det.

Den här artikeln handlar om detta missförhållande och vad du kan använda i stället. Om du är ett småföretag som väljer bokföringsprogram är QuickBooks sannolikt helt rätt val och ingenting av detta gäller dig.

Var den bristande anpassningen märks

En API-anslutning är en företagsfil. QuickBooks API är begränsat till ett företag, som identifieras med ett område (realm). En plattform som behöver bokföring för 300 säljande enheter hanterar 300 anslutningar och 300 prenumerationer, inte ett enda konto med 300 företag inuti. Det är oftast just denna sak som gör att utvärderingen avbryts.

API:et är ett komplement till applikationen, inte produkten. Funktioner dyker upp i gränssnittet och når API:et i sin egen takt. När hela din integration är beroende av att en funktion kan anropas är "tillgängligt i appen" inte samma sak som tillgängligt.

Hastihetsbegränsningen (throttling) är utformad för synkning, inte för transaktionsflöden. QuickBooks gränser beskrivs allmänt till 500 anrop per minut och företag, med hårdare begränsningar för batch- och rapportslutpunkter. Kontrollera alltid aktuella siffror mot Intuits egen utvecklardokumentation. Det är generöst för att synkronisera ett företags bokföring, men något helt annat när din plattform bokför transaktioner för tusentals företag i realtid.

EU:s gränsöverskridande skatter har luckor. Intuits eget supportmaterial anger att det inte finns någon standardrutin för att registrera IOSS-moms i QuickBooks och hänvisar användare till en bokförare eller revisor. För en plattform som säljer över EU:s gränser är distansförsäljning och hantering via One Stop Shop (OSS) inget specialfall, så detta är värt att kontrollera för dina specifika länder innan du bygger.

Inget av detta är felaktigheter. Det är konsekvenserna av att bygga en utmärkt applikation för företag som anlitar en bokhållare.

Vad "API, inte en app" faktiskt kräver

Innan vi jämför alternativ är det bra att definiera vad plattformsteam faktiskt efterfrågar, eftersom "har ett API" uppfylls av nästan allt.

Fullständig täckning. Allt som applikationen kan göra går att anropa. Nordlets ståndpunkt här är att appen inte har några privata slutpunkter – gränssnittet körs på samma slutpunkter som externa anropare får.
Flera företag under ett konto. Bokföring för många enheter utan en massa prenumerationer.
Idempotenta skrivningar. En förnyad begäran får inte skapa en andra faktura eller en dubblerad verifikation.
Händelsestyrning. Webhooks som triggas vid ändrade tillstånd, så att ert system reagerar i stället för att polla.
Genomdrivna bokföringsinvarianter. Obalanserade bokföringar avvisas, stängda perioder låses, bokförda dokument går inte att redigera.
Skatt som data, inte som ett skärmgränssnitt. Satser, regler för omsättningsland, valideringsresultat och register nås programmatiskt.
En testmiljö (sandbox) som matchar produktionen, samt obegränsat med testföretag så att integrationstester är billiga.

Utvärdera alla alternativ mot den listan i stället för mot en funktionsmatris.

Alternativen, uppdelat efter vad du försöker åstadkomma

Din situation	Välj	Varför
Din plattform måste ansvara för bokföringen för flera hyresgäster (tenants)	Ett inbäddat bokförings-API som till exempel Nordlet	Flera företag under ett konto, volymbaserad prissättning, bokföringsregler som tillämpas på serversidan
Dina kunder sköter bokföringen i QuickBooks och du integrerar med dem	Stanna kvar på QuickBooks API eller använd en aggregator	Bokföringen tillhör kunden; att möta dem där är rätt väg att gå
Du behöver bokföring i flera bokföringsprogram samtidigt	En aggregator som Codat, Rutter eller Merge	Ett enda gränssnitt över många underliggande system
Du behöver plånbokssaldon i realtid, inte lagstadgad bokföring	Reskontrainfrastruktur som Modern Treasury Ledgers	Byggt för genomströmning och omciftlighet (immutability), inte för skattedeklarationer
Du vill ha ett enda system för både drift och ekonomi	Ett affärssystem (ERP) som Odoo	Omfattning, till priset av att du driver det själv
Du är ett småföretag med en bokhållare	Xero, QuickBooks eller ett lokalt motsvarande system	Själva applikationen är det centrala

Inbäddat bokförings-API

Detta är det direkta svaret på "API, inte en app". Bokföringssystemet blir en backendlösning som din produkt anropar, och dina användare får aldrig se en huvudbok.

Nordlet är byggt för den här formen: en oföränderlig (immutable) dubbel bokföring reskontra där saldot upprätthålls av en databastrigger vid transaktionstillfället, löpande dokumentnumrering utan luckor, periodlåsning som avvisar bokföring med datum under en stängd månad med en 409-kod, en revisionslogg över varje ändring, stöd för Idempotency-Key som spelar upp det lagrade svaret vid ett nytt försök, samt signerade webhooks skrivna till en transaktionell utbox i samma databastransaktion som ändringen. Prissättningen är volymbaserad snarare än per företag: från 10 euro per månad med 3 000 anrop inkluderade, med obegränsat antal företag, användare och sandbox-företag på alla abonnemang.

De ärliga begränsningarna: Nordlet befinner sig i tidig åtkomst (early access) och onboarding av designpartners; EU-moms täcker satser per land, VIES-validering och beräkning av OSS/IOSS-deklarationer, men nationella deklarationspaket finns för närvarande för tre länder – Litauen (FR0600), Tyskland (UStVA) och Polen (JPK_V7M) – och lönehantering finns endast för Litauen.

Aggregatorer

Codat, Rutter och Merge ger dig ett enda gränssnitt till vilket bokföringssystem som helst som en kund redan använder. Om din produkts uppgift är att läsa eller skriva till dina kunders bokföring – utlåning, utgiftshantering, analys – är detta rätt kategori och en inbäddad reskontra vore fel. Om din plattform måste vara system of record kan en aggregator inte fylla den funktionen.

Reskontrainfrastruktur

Produkter i den här kategorien spårar saldon oföränderligt och med hög genomströmning utan att göra lagstadgad bokföring. De passar bra under en plånbok eller betalningsprodukt, men de lämnar moms, fakturering och årsredovisning till något annat.

Affärssystem (ERP)

Odoo och liknande sviter täcker mycket mer av verksamheten än bara bokföring. Avvägningen för plattformsutvecklare är integrationsytan: Odoos externa API fungerar på datamodellnivå via RPC, dess dokumentation anger att API-åtkomst är begränsad till Custom-prisnivån, och de nuvarande RPC-slutpunkterna är schemalagda för att ersättas av ett nyare JSON API. Detta tas upp i Nordlet vs Odoo för plattformsbyggare.

Om du migrerar bort från QuickBooks

Några saker som konsekvent tar längre tid än väntat:

Kontoplansmappning. Gör det metodiskt och behåll den gamla kontokoden som ett referensfält på det nya kontot. Du kommer att behöva det när någon frågar varför en jämförelsesiffra har flyttat på sig.
Ingående balanser. Migrera som saldon per ett visst stämdatum, inte som historik som bokförs på nytt. Låt det gamla systemet vara läsbart under lagringsperioden i stället för att försöka spela upp år av verifikationer på nytt.
Dokumentnumrering. Bestäm om nya serier ska fortsätta på den gamla numreringen eller börja om från början, och kontrollera kraven i din jurisdiktion innan du bestämmer dig.
Öppna poster. Obetalda fakturor, okontraherade krediter och delvis matchade betalningar måste komma in som öppna poster, inte som nettosaldon, annars kommer avstämningen inte att fungera efteråt.
Skatteperioder. Migrera inte mitt i en period om du inte är beredd att lämna in en deklaration från två system.
Kör båda under en cykel. Bokför samma månad i båda och jämför råbalansen innan du stänger av det gamla systemet.

FAQ

Finns det ett gratis alternativ till QuickBooks?

Det finns gratis bokföringssystem med öppen källkod, och Odoo erbjuder en gratistnivå som är begränsad till en applikation. Gratis förblir sällan gratis för en plattform, eftersom kostnaderna flyttas till hosting, uppgraderingar, regelefterlevnad och den nedlagda utvecklingstiden för att hålla en integration igång. Räkna på totalkostnaden, inte licensen.

Vad är bättre än QuickBooks för en marknadsplats?

För marknadsplatsobokföring specifikt passar ett inbäddat bokförings-API bättre strukturellt, eftersom det kan hantera bokföring för många enheter under ett enda konto, tillämpas bokföringsregler på serversidan och styras helt av din programvara. QuickBooks är fortfarande en bättre produkt för ett enskilt företag med en bokhållare.

Har QuickBooks ett API för utvecklare?

Ja. QuickBooks Online erbjuder ett OAuth 2.0 REST API med webhooks och en utvecklarportal. Begränsningen vid plattformsanvändning är inte API:ets kvalitet utan dess omfattning: det är utformat för att integrera med ett företags bokföring, inte för att vara reskontran inuti en annan produkt.

Kan jag behålla QuickBooks och lägga till ett bokförings-API?

Det kan du, och vissa team gör det: plattformens egna räkenskaper ligger i en inbäddad reskontra, medan integrationer skickar över sammanställda journaler till vilket bokföringssystem varje företagskund än använder. Regeln att hålla fast vid är att exakt ett system är den primära källan (system of record) för en given uppsättning räkenskaper. Två system som båda gör anspråk på att vara auktoritativa är hur avstämning问题的 börjar.

Vad sägs om Xero i stället?

Xero är ett starkt alternativ som applikation och har ett väldokumenterat API, men det har samma strukturella uppbyggnad: prenumerationer och API-gränser per organisation, och ocertifierade appar är begränsade till 25 anslutna organisationer. Jämförelsen finns beskriven i Nordlet vs Xero för inbäddad bokföring.