Debet & KreditDebet & Kredit
Köp — 1 995 kr

Recept

Webshop → fakturautkast

Din butik eller ditt kassasystem lämnar ordern till bokföringen, och den blir ett fakturautkast med kund, artiklar, konto och moms på plats — genom exakt samma väg som fakturaformuläret i programmet.

Debet & Kredit kör på din egen server, så bas-URL:en är din — inte vår. Skriv in den här, så byts den ut i varje kodexempel i dokumentationen.

Det finns inga plattformskopplingar

Ingen Shopify-, WooCommerce- eller Fortnox-adapter, och det är ett val — inte något som saknas.

En adapter mot någon annans API går inte att bygga rätt utan ett riktigt konto att pröva mot. Skriven efter dokumentationen och aldrig körd skarpt är den en gissning, och en gissning om moms blir ditt myndighetsfel, inte vårt. Varje adapter är dessutom löpande underhåll mot ett gränssnitt någon annan ändrar när de vill: tjänstedrift förklädd till funktion.

I stället finns ett generiskt orderformat. Butiken anropar adressen själv, eller via ett mellanled du väljer — Zapier, Make, eller tjugo rader kod i din egen serverfunktion. Har du en fil i stället läser du in den under Order i programmet.

Med ett undantag, och undantaget bevisar regeln. WooCommerce går att starta i en Docker-container, och därför finns en liten fristående översättarmall i ditt eget repo under integrations/woocommerce-bridge/. Den körs på DIN Vercel, inte vår, och den levereras bara därför att dess enda laddade påstående — att Woo alltid lämnar radens belopp i netto — mäts i CI mot två riktiga Woo-butiker med olika prisinställning. För Shopify finns inget sådant prov att köra, och därför finns där ett recept i stället för en mall.

Så här ser anropet ut

Skapa en nyckel med behörigheten Ta emot underlag under Inställningar → API-nycklar. Den kan lämna in ordrar och ingenting annat — den ser inte ens vad som redan finns i bokföringen.

curl -X POST "https://din-installation.se/api/inbound/order" \
  -H "Authorization: Bearer dk_live_DIN_NYCKEL" \
  -H "Content-Type: application/json" \
  -d '{
  "externalId": "SHOP-10042",
  "orderDate": "2026-03-12",
  "currency": "SEK",
  "pricesIncludeVat": true,
  "total": 1249,
  "customer": {
    "name": "Anna Andersson",
    "email": "anna@example.com",
    "countryCode": "SE"
  },
  "rows": [
    {
      "description": "Träningsbälte",
      "quantity": 1,
      "unitPrice": 1249,
      "vatRate": 25
    }
  ]
}'

Tre saker som avgör om det blir rätt

1. pricesIncludeVat är obligatoriskt

Det går inte att se på ett tal om momsen ingår, och att anta fel gör varje rad 25 procent fel. Är priserna inklusive moms krävs också total — vad kunden faktiskt betalade — så att baklängesräkningen kan stämmas av mot totalen i stället för att lita på summan av raderna.

2. externalId hindrar dubbletter

Butikens ordernummer är nyckeln. Samma nummer kan aldrig bli två fakturor, hur många gånger butiken än levererar om. Ett omförsök svarar { "ok": true, "duplicate": true } med samma fakturautkast — alltså inte ett fel, utan ett kvitto på att ordern redan är mottagen.

3. En spärrad order försvinner aldrig

Går ordern inte att kontera rätt svarar rutten 422 — och ordern sparas ändå, med sitt skäl, i listan över mottagna ordrar. Den går att rätta och skicka om. En spärrad order som försvann hade varit omöjlig att skilja från en order som aldrig kom.

{
  "ok": false,
  "blocked": true,
  "reason": "Konsument i annat EU-land — unionsintern distansförsäljning ska redovisas i OSS.",
  "journaled": true
}

Vad som spärras, och varför

En order till en konsument i ett annat EU-land spärras. Det är unionsintern distansförsäljning som ska beskattas i köparens land och redovisas i OSS — inte faktureras med svensk moms, och inte med omvänd betalningsskyldighet, som bara gäller näringsidkare. Programmet har ingen OSS-redovisning, och då ska det säga det i stället för att bokföra fel moms i fel land.

Artiklar slås upp men skapas aldrig automatiskt. Ett artikelregister som fylls på av varje order är inget register. Saknas artikeln konteras raden på det intäktskonto som passar momssatsen.

När du hellre vill skicka en färdig faktura

Orderintaget tar en butiksorder som ska tolkas: kunden kanske inte finns, kontot ska härledas, momsen räknas baklänges ur ett bruttopris. Vet du redan vilken kund det gäller och vilka konton raderna ska ha är POST /api/v1/kundfakturor rätt väg — den tar en färdig faktura och kan bokföra den direkt.

Vidare