Fakturans PDF läses, leverantören matchas och konteringen föreslås. AI:n läser beloppen ur fakturan, och moms och balans räknas i vanlig kod med enhetstester. Ligger det en inköpsorder bakom matchas fakturan mot inleveransen rad för rad.
Det är regeln hela konteringen är byggd på. AI:n läser fakturans belopp ur PDF:en och föreslår konto, momsnivå och art — sedan räknar deterministisk kod momsen, löneskatten och balansen, och ni ser beloppen bredvid PDF:en innan något bokförs. Det gör förslaget granskningsbart i stället för att kräva tillit.
Prompten innehåller er aktiva kontoplan under rubriken "Tillåtna konton" med instruktionen att aldrig hitta på ett nummer. Kommer ett okänt konto tillbaka kastas det i kod. För pensionsarter räcker det inte att numret finns — kontots namn i er plan måste passa arten.
Ingående moms fördelas per momssats till rätt momskonto, inte till ett enda. Omvänd skattskyldighet räknas som netto gånger sats och bokar båda benen — fällan att en faktura utan moms tappar momsbenen är stängd.
Konton ni tidigare bokfört den här leverantören på rankas upp och märks — alternativen visar "Använt 14 ggr för leverantören". Systemet lär sig av era beslut utan att någon modell tränas på er data.
Svarar modellen inte får ni historikbaserade förslag eller ett tomt förslag och konterar manuellt. Rader som inte summerar till fakturans netto förkastas som uppdelning och blir en flaggad klumprad i stället för en felaktig split.
Det här är skillnaden mot ett bokföringsprogram: lagret och inköpet ligger i samma huvudbok, så fakturan kan prövas mot vad som faktiskt kom in på lagret.
Pris och kvantitet som beställdes.
Det som faktiskt kom, bokfört mot interimskontot.
Matchas rad för rad — bara mot rader som har en mottagning.
Matchningen visar per rad var fakturan skiljer sig från inleveransen i pris och antal, och ni bekräftar. Bokas fakturan i stället mot inköpsorderns totalbelopp blir avvikelsen egna verifikatrader, med örena på öresavrundning. Ligger den över er tolerans stannar fakturan tills någon har valt hur den ska hanteras — som prisavvikelse, mot interimskontot eller parkerad under utredning.
Innan en faktura får skickas till betalning summerar servern kontot för differenser under utredning (förvalt 1485) över inköpsorderns hela omfång — ordern, förmatchade fakturor och radmatchade fakturor. Ligger ett öre eller mer kvar blockeras betalningen. En kreditnota på samma order släpper spärren automatiskt.
Förmatchning — fakturan kommer före varorna — och inleverans läser samma inställning, så de nettar mot varandra per order. En andra faktura på samma inköpsorder nettas mot vad huvudboken faktiskt visar återfört, inte mot en uträkning som kan ha drivit isär.
Makuleras en bokförd faktura speglas de faktiska verifikatraderna, debet mot kredit — inte en ny uträkning från dagens inställningar. Återföringen nettar därför till noll även om konton, moms eller toleranser ändrats sedan bokföringen.
Rapporten visar vad som kommit in men ännu inte fakturerats, och fördelar fakturasidan tillbaka på rätt inköpsorder viktat på radvärde — även när faktura och order ligger på olika id:n. Avskrivningen använder samma fördelning, så det ni bokför bort är det rapporten visade.
AI:n bokför aldrig själv. Varje faktura kräver ett godkännande, och radmatchningen föreslås och ni bekräftar — det är ingen tyst automatik i bakgrunden. Trepartsmatchningen förutsätter att inleveransen faktiskt bokförts med verifikat; en mottagning som bara registrerats driver inte återföringen. Kostnadskonteringen sker på fakturans huvudbelopp med en fraktrad, inte per produktrad — det är pensions- och försäkringsfakturor som delas per art.
Vi kör dem genom konteringen och trepartsmatchningen och visar förslagen — inklusive de som hade stoppats.