OIOUBL faktura til Excel: felter, linjer og moms

En brugbar konvertering fra OIOUBL faktura til Excel bevarer både fakturaniveau og fakturalinjer. Hvis regnearket skal bruges til bogføring, momsreview eller kontrol af varelinjer, bør det normalt have én række per fakturalinje, mens centrale fakturafelter som fakturanummer, dato, kreditor, debitor, valuta, referencer og betalingsoplysninger gentages på hver række.

Det kan se redundant ud i Excel, men det er netop det, der gør filen anvendelig. Når hver linje bærer sin egen fakturakontekst, kan en bogholder filtrere på leverandør, ordre, konto, momsrate eller betalingsstatus uden først at skulle slå op i et separat XML-dokument.

OIOUBL XML er allerede struktureret. Problemet er ikke, at dataene mangler. Problemet er, at en faktura i XML består af flere lag: fakturahoved, parter, betalingsoplysninger, totaler, momsopdelinger og linjer. Når de lag skal flades ud til et regneark, skal du vælge, hvad én række i Excel betyder.

Hvis du kun skal have et fakturaregister, kan én række per faktura være nok. Hvis du skal kontrollere bogføring, udtrække fakturalinjer fra OIOUBL, afstemme moms eller analysere indkøb på vareniveau, er én række per fakturalinje den stærkere form. Det er forskellen mellem en liste over modtagne fakturaer og et regneark, der faktisk kan forklare, hvad fakturaerne indeholder.

Vælg mellem én række per faktura og én række per fakturalinje

En én-række-per-faktura model passer bedst til et register. Den kan vise fakturanummer, leverandør, køber, dato, forfald, valuta, totalbeløb, betalingsreference og status. Det er en praktisk form, når formålet er betalingsopfølgning, leverandøroversigt, importforberedelse på hovedniveau eller et hurtigt overblik over modtagne NemHandel-fakturaer.

Den model bliver svag, så snart spørgsmålet handler om indholdet af fakturaen. Hvis en faktura har ti linjer, forskellige varebeskrivelser, rabatter, projektkoder eller forskellige momsbehandlinger, mister du forklaringen, hvis alt presses ind i én totalrække. Du kan stadig se, hvad der skal betales, men ikke hvorfor beløbet ser ud, som det gør.

En én-række-per-fakturalinje model gør hver linje analyserbar. Fakturanummer, leverandør, køber, dato, valuta og betalingsreference gentages på hver linje, mens linjens varenavn, antal, enhedspris, rabat, moms og nettobeløb får egne kolonner. Det giver flere rækker, men færre blinde vinkler.

Samme designproblem findes i andre e-fakturaformater. En artikel om norsk EHF XML til Excel eller Singapore InvoiceNow XML til Excel vil have andre feltnavne og lokale regler, men det grundlæggende valg er det samme: skal regnearket vise fakturaer som dokumenter, eller skal det vise linjer, der kan kontrolleres?

Fakturahovedet: kolonnerne der giver kontekst

Fakturahovedet er den del af OIOUBL-fakturaen, der forklarer dokumentet som helhed. I Excel bør det normalt blive til kolonner for fakturanummer, udstedelsesdato, eventuel forfaldsdato, valuta, dokumenttype, totalbeløb og filnavn. Filnavnet er ikke et regnskabsfelt, men det er nyttigt, når regnearket senere skal spores tilbage til den oprindelige XML-fil.

Parterne skal også med. For kreditor og debitor er navn, CVR, EAN eller GLN, samt relevante adressefelter typiske kolonner. Adressefelter er ikke altid nødvendige i et arbejdspapir, men identifikatorerne er vigtige, fordi navn alene kan være upræcist, især hvis samme koncern, afdeling eller offentlige enhed optræder på flere måder.

Referencer fortjener egne kolonner i stedet for at blive gemt i en samlet bemærkningskolonne. Ordrenummer, rekvisitionsnummer, buyer reference, kontraktreference, projektreference og leverandørens betalingsreference kan være det, der afgør, om en faktura kan matches mod indkøb, projektøkonomi eller intern godkendelse.

Betalingsoplysninger bør behandles som strukturerede data. Betalingsmiddel, betalings-ID, bankkonto, betalingsbetingelser og det beløb, der faktisk skal betales, er ikke blot tekst på fakturaen. De er felter, en bogholder kan bruge til betalingsopfølgning og afstemning.

Den officielle kontrolside understøtter, hvorfor disse felter ikke er pynt. NemHandel/OIOUBLs valideringsregler for fakturaer kræver blandt andet fakturanummer, udstedelsesdato, valuta, sælger- og købernavn, totalbeløb, betalingsbeløb, mindst én fakturalinje, linjemængde, linjenettobeløb, varenavn, nettopris, momsopdeling og betalingsinstruktioner. En god Excel-konvertering gør de samme forretningsoplysninger synlige som kolonner, så de kan kontrolleres uden at åbne XML'en for hver faktura.

Fakturalinjer, moms og rabatter må ikke smelte sammen

Fakturalinjerne er der, hvor regnearket bliver nyttigt for bogføring. Hver linje bør som minimum kunne vise linjenummer, varenavn eller ydelsesbeskrivelse, antal, enhed, enhedspris, eventuel rabat, linjens nettobeløb, momskategori, momssats og linjetotal. Hvis OIOUBL-filen indeholder linjespecifikke tillæg, gebyrer eller rabatter, bør de ikke skjules i én samlet difference.

Momsfelter kræver særlig disciplin. Fakturaens totalmoms, momsgrundlag og linjernes momsoplysninger hænger sammen, men de er ikke det samme felt. En faktura kan have almindelige momspligtige linjer, momsfritagne linjer, rabatter, fragt eller andre beløb, der påvirker momsopdelingen. Hvis Excel-udtrækket kun viser én momssats og ét momsbeløb, kan det se pænt ud, men være for groft til kontrol.

En praktisk model er at lade linjearket bære de felter, der forklarer hver vare- eller ydelseslinje, og samtidig have tydelige kolonner for fakturatotaler: linjesum, momsgrundlag, momsbeløb, total inklusiv moms og beløb til betaling. Når linjesummerne ikke stemmer med totalerne, skal regnearket gøre det muligt at finde årsagen, ikke skjule forskellen.

Det er også her, forskellen mellem validering og Excel-brugbarhed bliver tydelig. En OIOUBL-faktura kan være gyldig, selv om en eksport til Excel gør den svær at arbejde med. Hvis konverteringen samler linjer, fjerner rabatter eller placerer momsopdelingen i en ustruktureret tekstkolonne, har du ikke længere et regneark til bogføringsreview. Du har kun et teknisk uddrag.

Bevar audit-sporet fra XML til regneark

Et Excel-udtræk fra OIOUBL bør ikke kun være læsbart. Det bør også kunne forklares. Når en kollega, kunde eller revisor spørger, hvor et beløb kommer fra, skal regnearket kunne pege tilbage på den oprindelige fil og det relevante felt.

Praktiske kildekolonner kan være originalt filnavn, dokument-ID, leverandørens fakturanummer, modtagelseskanal, udtræksdato og et stabilt række-ID for hver fakturalinje. I mere tekniske arbejdsgange kan en XML-sti eller et kildefelt også være værdifuldt, især når valgfri OIOUBL-felter bruges forskelligt fra leverandør til leverandør.

Det kan være fristende at fjerne alt, der ikke ligner en klassisk Excel-rapport. Men et helt rent ark kan blive svagt som arbejdspapir, hvis det ikke længere viser, om et beløb kom fra fakturahovedet, en fakturalinje, en momsopdeling eller en betalingssektion. Sporbarhed er ikke støj, når regnearket bruges til kontrol.

Konteksten er også blevet vigtigere, fordi digital bogføring og dokumentation hænger tættere sammen i danske økonomifunktioner. En særskilt gennemgang af Danmarks digitale bogføringskrav dækker den compliance-side; i en OIOUBL-til-Excel-arbejdsgang er den praktiske pointe, at kildeoplysninger skal overleve konverteringen.

Brug feltkortet som kravspecifikation før konvertering

Før du konverterer OIOUBL XML til Excel, bør du beslutte, hvad regnearket skal kunne svare på. Et fakturaregister kræver ikke samme detaljer som en momsafstemning. En bogføringsimport kræver ikke nødvendigvis samme kolonner som et review af varelinjer, rabatter og projektreferencer.

Start med arketypen: én række per faktura, én række per fakturalinje, et særskilt momsark eller en kombination. Skriv derefter felterne ned i grupper: fakturahoved, kreditor og debitor, EAN/GLN/CVR, ordre- og rekvisitionsreferencer, betalingsoplysninger, fakturalinjer, momsopdeling, totaler og kildeoplysninger.

Den korte kravspecifikation gør konverteringen mindre tilfældig. Den fortæller, hvilke OIOUBL-felter der skal være kolonner, hvilke fakturafelter der skal gentages på linjeniveau, og hvilke kildefelter der skal bevares for kontrol. Den gør det også lettere at opdage et dårligt udtræk, før nogen bruger regnearket som grundlag for bogføring.

Den bedste Excel-fil er ikke nødvendigvis den med færrest kolonner. Det er den, der bevarer det regnskabsspørgsmål, du skal svare på: hvad blev købt, af hvem, til hvilken pris, med hvilken momsbehandling, med hvilke referencer, og hvor kan beløbet spores i den oprindelige OIOUBL-faktura?