Fakturatvister og e‑fakturaer som bevis

En fakturatvist ser enkel ud: Der er sendt en faktura, og den er ikke betalt. Men bag uenigheden ligger ofte spørgsmål, som kun data kan besvare. Blev fakturaen sendt og modtaget? Er den ændret undervejs? Hvilken version gælder, når der er udstedt kreditnotaer? Og hvor endte betalingen, hvis kunden siger, at den er betalt?

Om kravet består, og hvilke rente- og gebyrregler der gælder, er advokatens vurdering. Her handler det om de digitale spor og om, hvordan de sikres, før de ændres.

Tre slags fakturaer, tre slags spor

• PDF sendt med mail · Mailen i afsenderens og modtagerens postkasse, serverlogs, PDF-filens metadata
• E-faktura i struktureret format · XML-filen, kvitteringer fra adgangspunkt eller fakturaportal, modtagerens bogføringssystem
• Faktura i en kundeportal · Portalens log over upload, visning og download

En e-faktura er grundlæggende en datafil, typisk XML i et standardformat som OIOUBL eller Peppol BIS. Det, kunden ser på skærmen, er en visning af filen. Det er derfor filen og ikke skærmbilledet, der skal sikres. Visningen kan være forskellig fra system til system, og felter i filen vises ikke altid.

Ved e-fakturaer sendes dokumentet gennem et netværk af adgangspunkter. Om der findes en kvittering for afsendelse eller for modtagelse, og hvor detaljeret den er, afhænger af de systemer, parterne bruger. Spørg begge parters leverandører, før dataene udløber.

Hvem har data?

• Afsenderen: fakturaen i regnskabs- eller faktureringssystemet, systemets ændringslog, den sendte mail eller e-fakturafilen og eventuelle kvitteringer.
• Modtageren: den modtagne mail eller fil, bogføringssystemets registrering af modtagelse, godkendelsesflow og betalingsforslag.
• Leverandører: udbyderen af regnskabssystemet, e-fakturatjenesten eller mailtjenesten kan have logs, som parterne ikke selv kan se.
• Banker: kontoudtog, betalingsreferencer og oplysninger om modtagerkontoen.

Klienten har normalt kun sin egen side. Modpartens data kræver typisk en henvendelse eller edition.

Hvad der sikres først

1. Den originale faktura i det format, den blev sendt i, og ikke en ny udskrift fra systemet. En faktura, der genereres på ny, kan få andre metadata og i nogle systemer et ændret indhold.
2. Ændringslog og historik i regnskabssystemet for den pågældende faktura, kreditnotaer og kundekonto.
3. Afsendelsesspor: den sendte mail med headere, logs i faktureringssystemet og eventuelle kvitteringer. → Hvornår er en mail kommet frem?
4. Betalingsspor: kontoudtog og bankens oplysninger om indbetalinger med reference.
5. Aftalegrundlaget: tilbud, ordrebekræftelser og timeregistreringer, som fakturaen bygger på.

Bogføringsreglerne kræver, at virksomheder opbevarer bilag i en årrække, og nyere regler stiller krav til digitale bogføringssystemer. Det betyder ikke, at alle logs og metadata gemmes lige så længe. Ændringslogs og mailspor kan have kortere opbevaring. → Bevissikring af regnskabssystemer

Hvad data kan og ikke kan vise

Typisk kan data vise:

• hvornår en faktura blev oprettet, ændret og sendt fra afsenderens system,
• om et fakturanummer passer ind i nummerrækken,
• om en mail med fakturaen blev modtaget af modtagerens mailserver,
• om en betaling med en bestemt reference er gået ind på en bestemt konto.

Typisk kan data ikke vise:

• at nogen hos modtageren har læst fakturaen,
• at fakturaens indhold er i overensstemmelse med aftalen,
• at arbejdet eller varen faktisk er leveret,
• hvorfor en betaling ikke er sket.

Det sidste skal dokumenteres med andet materiale. Data om afsendelse og modtagelse flytter fokus fra “vi har aldrig fået den” til det, sagen egentlig handler om.

Når fakturaen er ændret

Hvis parterne fremlægger hver sin version af samme faktura, er spørgsmålet, hvilken der er den oprindelige. Den sagkyndige kan sammenholde:

• regnskabssystemets historik for fakturaen,
• metadata i PDF-filen, fx oprettelsesprogram og tidspunkter,
• vedhæftningen i den sendte mail, der kan have en kendt hashværdi i postkassen,
• e-fakturafilen, hvis den findes.

PDF-metadata kan ændres, og en PDF, der er gemt igen, får nye værdier. Metadata er derfor ét indicium blandt flere. → Dokumentforfalskning i Office og PDF

Afviste e-fakturaer og kundeportaler

Mange modtagere, især offentlige og større virksomheder, validerer e-fakturaer automatisk. En faktura med en manglende ordrereference, et forkert identifikationsnummer eller en formfejl kan blive afvist, uden at nogen hos modtageren ser den. Hvis afsenderen ikke opdager afvisningen, kan parterne stå med hver sin opfattelse af, om der er faktureret.

Sikr derfor også eventuelle afvisninger eller fejlmeddelelser fra afsenderens e-fakturatjeneste. De kan forklare et forløb, som ellers ligner manglende betaling.

Når fakturaer lægges i en kundeportal, er portalens log den vigtigste kilde. Den kan vise upload og eventuelt visning eller download fra kundens brugere. Logs i portaler drives ofte af en leverandør, og opbevaringstiden kan være kort. Bed om en eksport tidligt.

Når betalingen er gået til en forkert konto

En særlig type tvist opstår, når kunden har betalt til et kontonummer, der ikke tilhører leverandøren, fx fordi en faktura blev ændret i en mail, der var blevet opsnappet. Så handler sagen om, hvem der bærer tabet.

Her er spørgsmålene tekniske: Hvilken mailkonto blev kompromitteret, hvornår, og hvordan kom den ændrede faktura frem? Svaret kan ligge i begge parters mailsystemer, loginlogs og mailheadere. Det haster, fordi loginlogs ofte har kort opbevaringstid. → Betalingstvister og dokumentation

Mange fakturaer på én gang

Nogle tvister handler ikke om én faktura, men om en hel samarbejdsperiode med løbende fakturering, kreditnotaer, delbetalinger og modregninger. Her er det sjældent den enkelte faktura, der er problemet, men afstemningen. Parterne kommer let til at tale forbi hinanden, fordi deres systemer viser saldoen forskelligt.

En IT-sagkyndig kan hjælpe med at lave en afstemning direkte fra systemernes data: en tabel, hvor hver faktura, kreditnota og betaling står med nummer, dato, beløb og den kilde, oplysningen kommer fra. Afvigelser mellem parternes systemer markeres, så det bliver tydeligt, hvilke poster der faktisk er uenighed om. Det forudsætter, at begge parters data foreligger som eksport og ikke kun som saldolister.

Den sagkyndige kan derimod ikke afgøre, hvordan en betaling uden reference skal fordeles, eller om en kreditnota var aftalt. Det er spørgsmål om aftalen og om, hvad parterne har kommunikeret, og det skal belyses med mails, ordrebekræftelser og forklaringer.

Typiske fejl

• Klienten fremlægger en ny udskrift fra regnskabssystemet i stedet for den faktura, der blev sendt.
• E-fakturaen fremlægges kun som skærmvisning, ikke som datafil.
• Regnskabssystemet skiftes eller opsiges, før historikken er eksporteret.
• Kreditnotaer og delbetalinger er ikke koblet til de rigtige fakturaer.
• Tidsstempler fra systemer i forskellige tidszoner sammenlignes direkte.
• Man går ud fra, at en sendt mail er en modtaget mail.

Spørgsmål til klienten

• Hvordan blev fakturaen sendt, og fra hvilket system?
• Er fakturaen ændret, krediteret eller udstedt igen?
• Hvilke kvitteringer eller svar er modtaget fra modtageren eller fra systemet?
• Hvilke betalinger er modtaget fra kunden i perioden, og med hvilke referencer?
• Hvornår udløber abonnementet på regnskabs- eller faktureringssystemet?

Spørgsmål til skønsmanden

• “Hvornår blev fakturaen med det angivne nummer oprettet, ændret og sendt ifølge systemets historik?”
• “Svarer den fremlagte PDF til vedhæftningen i den sendte mail?”
• “Er der i de sikrede logs spor af, at mailen blev modtaget af modtagerens mailserver?”

Tjekliste

• ☐ Original faktura sikret i afsendt format
• ☐ Ændringslog og historik eksporteret
• ☐ Mail eller e-fakturafil sikret med headere og kvitteringer
• ☐ Kontoudtog og betalingsreferencer samlet
• ☐ Aftalegrundlag og leveringsdokumentation samlet
• ☐ Leverandører bedt om at bevare logs

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT