TL;DR
En OCR-referens är fakturanumret med en kontrollsiffra sist, och kontrollsiffran är hela poängen: banken avvisar en felskriven referens i betalningsögonblicket i stället för om fjorton dagar, och en inbetalning vars referens går ihop kan matchas mot en faktura av en maskin i stället för av en människa. Samma räknande vaktar ert eget bankgironummer, som är fältet på en faktura med det värsta felläget av alla.
Att bygga referensen
Två varianter förekommer och banken avgör vilken.
Mjuk är numret plus en Luhn-kontrollsiffra. Faktura 1043, räknat från höger: varannan siffra dubbleras, och allt som når tio får nio avdraget.
siffra 1 0 4 3
dubblas nej ja nej ja
värde 1 0 4 6 → summa 11
Kontrollsiffran är det som gör summan jämnt delbar med tio, alltså 9. Referensen blir 10439.
Hård lägger in en längdsiffra före kontrollsiffran, så att banken också kan avvisa en referens med rätt siffror i fel antal. Längdsiffran räknar den färdiga referensen inklusive sig själv och kontrollsiffran — för 1043 blir det 4 + 2 = 6, och bara längdens sista siffra får plats. Kroppen blir 10436, vars kontrollsiffra är 4, och referensen blir 104364. Sex siffror lång, precis som den sjätte siffran påstår.
Varför bry sig om längdvarianten? En siffra som tappas mitt i passerar Luhn ungefär en gång på tio. Längdkontrollen är det som fångar resten.
Vad Luhn lovar, och vad den inte lovar
Luhn är här samma algoritm som på ett kortnummer, och därför är det värt att säga exakt vad den gör. Den fångar varje enstaka felskriven siffra och nästan varje omkastning av två intilliggande. Det täcker den absoluta merparten av vad en människa skriver fel.
Den är ingen signatur. En referens som går ihop är en referens som förmodligen skrevs rätt, inte en som säkert är er. Den skillnaden avgör vad betalningsmatchningen får göra på egen hand, längre ned.
De besvärliga kanterna
Allt som inte är siffror strippas. Ett fakturanummer som 2026-A-0042 är fullständigt vanligt och en bankreferens kan inte bära bindestrecken.
Inledande nollor följer med. De bär ingen information genom ett system som behandlar referensen som ett tal, och att behålla dem skulle bara få längdsiffran att ljuga.
Tjugofem siffror är taket. Längre än så avvisas betalningen i bankens kassa, vilket är ett sämre fel än ett långt fakturanummer: kunden ville betala och kunde inte. Alltså avvisas ett fakturanummer som är för långt för att bära en referens med ett meddelande när referensen byggs, i stället för att kapas till något som pekar på en annan faktura.
En kreditfaktura får ingen referens alls. Pengar betalas aldrig in på ert konto mot en sådan. Värre: att ge den en referens vore aktivt skadligt, eftersom fakturor och kreditfakturor räknar på oberoende serier, så kreditfaktura 1 och faktura 1 reduceras till samma siffror och därmed samma OCR. Matchningen skulle hitta två dokument till en inbetalning utan något sätt att välja.
Ert eget gironummer bär samma kontroll
Bankgironummer är sju eller åtta siffror; plusgiro löper från två till åtta. Båda slutar med en Luhn-kontrollsiffra — samma räknande som betalningsreferensen.
Det här är det värsta fältet på en faktura att få fel. Ett felskrivet organisationsnummer är pinsamt. Ett felskrivet gironummer trycks på varje faktura företaget skickar, och det tillhör antingen ingen, i vilket fall betalningarna studsar i veckor, eller någon annan, i vilket fall de inte gör det. Kontrollsiffran gör det första utfallet säkert och det andra närapå omöjligt, och därför valideras numret när ni skriver in det i inställningarna snarare än när en kunds betalning spårar ur.
Var referensen färdas
I ett CAMT.053-utdrag kan referensen ligga på tre ställen, och de är inte lika pålitliga:
- Den strukturerade betalarreferensen. Det är fältet ett OCR-nummer hör hemma i, och det enda banken har validerat.
- De ostrukturerade meddelanderaderna. Där den brukar ligga i stället.
- Bankens egen prosa om posten. Läses sist, eftersom att matcha på den är att matcha på en mening.
Tre sätt att ha rätt, och bara ett som bokförs självt
En inbetalning matchas i tre nivåer.
OCR. Referensen passerar Luhn och leder till exakt en öppen faktura. Det här är så nära säkert man kommer, och det är den enda nivån som får bokföra en betalning utan en människa.
Fakturanummer i meddelandefältet. Någon har skrivit noggrant, vilket oftast stämmer och ibland är förra månadens fakturanummer. Ett förslag.
Ett unikt utestående belopp. En slump som oftast inte är en slump. Också ett förslag.
Skälet till att de två sista väntar är att en automatisk bokföring är fel två gånger om i samma ögonblick: fakturan som inte betalades markeras reglerad och slutar jagas, och kunden som faktiskt betalade får en påminnelse. Av de två felen är det andra det som kostar relationen.
Två detaljer får nummernivån att uppföra sig. Tecken kortare än tre ignoreras — en organisation vars första faktura heter 1 skulle annars få den föreslagen mot varje meddelande som innehåller en etta, vilket är de flesta. Och nummer matchas som hela tecken i stället för som delsträngar, eftersom faktura 42 annars hittas inuti faktura 142 och fel av de två föreslås ungefär lika ofta som rätt.
En rad som leder till två kandidater leder till ingen, och förblir synlig med båda kandidaterna kvar. "En av de här tre" är betydligt mer värt för en människa än tystnad.
Att få in kontoutdraget över huvud taget
Ingen matchning spelar någon roll om filen läses slarvigt, så importen avvisar mer än den accepterar.
CAMT.053 och CSV. Det första tecknet som inte är blanksteg avgör vilket — XML börjar med en tagg och ingen CSV-rubrik gör det. Filändelsen rådfrågas inte, eftersom en CAMT-fil sparad som .csv är fullt vanlig och att lita på ändelsen skulle tolka den som en enda kolumn.
En trasig fil avvisas hel, aldrig rad för rad. Ett utdrag som importerats med en rad tyst borttappad stämmer mot ingenting och upptäcks, om alls, av en bokförare ett kvartal senare. Att låta importen falla lämnar filen på disken och problemet framför den som kan rätta det.
Tvetydiga belopp avvisas. Strängen 1,234 är antingen 1 234 kronor eller 1,23 kronor, och de två tolkningarna skiljer sig med en faktor tusen. En avskiljare följd av en eller två siffror är en decimalavskiljare, en följd av exakt tre i ett tal utan andra avskiljare är ingetdera, och filen stannar där.
Bara ISO-datum. 03/04/2026 är den tredje april för halva Europa och den fjärde mars för resten, och en betalning bokförd i fel månad hamnar i fel momsperiod — vilket upptäcks av Skatteverket snarare än av er.
En återföring vänder tecknet. CAMT märker en studsad betalning som en post med riktningen upphävd. Läst utan den flaggan är den ett andra inbetalningstillfälle, och fakturan blir reglerad av en betalning som kom rakt tillbaka.
En post utan riktning avvisas rakt av. Utan den anger filen ett belopp men ingen riktning, och en kredit läst som en debet reglerar en faktura ur någon annans utgående hyresbetalning.
Samma fil importerad två gånger fångas. Av bankens eget utdrags-id där det finns, och av en summa över byten där det inte gör det — ingen som granskar en matchning kan skilja en äkta andra betalning på samma belopp från en fil som importerats två gånger.
Import av kontoutdrag ligger i Pro-nivån; själva betalningsmatchningen ligger i Väx och Pro.
Beloppsnivån och ROT-problemet
Beloppsnivån jämför mot det kunden fortfarande är skyldig: totalen, minus det Skatteverket reglerar, minus det som redan kommit in.
Det betyder mer än det låter. En faktura på 10 000,00 kr med 5 000,00 kr avdragsgill arbetskostnad inklusive moms bär ett ROT-avdrag på 1 500,00 kr, så kunden för över 8 500,00 kr. En matchning mot den tryckta totalen skulle inte hitta någonting alls — nivån som finns till för kunden som för över exakt rätt belopp utan referens skulle missa precis de fakturor där rätt belopp inte är det tryckta.
Vad fakturan skriver ut
Bankgiro och plusgiro i den form registret själv publicerar, IBAN och BIC där de är satta, förfallodagen, och OCR-referensen i en egen ruta med stor text. En kund som jämför numret på fakturan med det på bankskärmen jämför formen lika mycket som siffrorna.