Slik unngår du å betale feil leverandørfakturaer – uten å endre hele fakturaprosessen

En leverandørfaktura kommer inn til godkjenning, men beløpet er høyere enn forventet. Kanskje er en pris endret, eller fakturaen inneholder et tillegg som ingen kjenner igjen. Prosjektlederen blir bedt om å kontrollere den, men uten en enkel oversikt over bestilling, leveranse og faktura er det vanskelig å fastslå hva som er riktig. Til slutt blir fakturaen godkjent likevel. Leverandøren skal ha betalt, og prosjektet må videre.

Seks uker senere viser økonomirapporten at prosjektet ligger over budsjett. Det er ikke sikkert noen kobler overskridelsen til fakturaen som allerede er betalt.

Feilbetalinger er blant de dyreste problemene i prosjektbasert økonomi, og blant de minst omtalte. De koster penger hver måned, og det vanlige svaret, å kjøpe et system for fakturaflyt, løser dem ofte bare delvis. Slike systemer er først og fremst laget for å behandle og betale fakturaer raskere. Problemet her er fakturaer som ikke skulle vært betalt slik de ble fakturert.

Hvorfor bedre fakturaflyt ikke alltid er nok

Spør du økonomiledere hvordan de vil unngå feilbetalinger, er svaret ofte at de trenger bedre fakturaflyt. Det virker logisk. Fakturaene kommer inn til regnskapsavdelingen, så det er der problemet må løses.

Men se på hva slike systemer i hovedsak er laget for. De henter inn fakturadata, sender fakturaer raskere videre til godkjenning, kontrollerer mot leverandørregisteret og klargjør betalinger. Målet er å korte ned tiden fra en faktura mottas til den betales, med betaling på dager i stedet for uker, mindre manuell registrering, bedre sporbarhet og fornøyde leverandører. Mange av dem har også kontrollfunksjoner, men uten tilgang til bestilling og varemottak kan de bare kontrollere det fakturaen selv inneholder.

Raskere behandling alene løser derfor ikke problemet med en faktura som ikke stemmer med innkjøpsordren.

Uten kobling til bestilling og varemottak sender et system for fakturaflyt en feil faktura til godkjenning like effektivt som en riktig. Automatiseringen gjør da bare at feilen blir betalt raskere.

Det avgjørende spørsmålet, skal denne fakturaen betales slik den er?, må besvares før fakturaen går videre i flyten. Derfor opplever mange virksomheter som har investert i raskere fakturabehandling, at overbetalinger og uavtalte tillegg fortsatt forekommer to år senere. Systemet behandlet fakturaene raskt, men hadde ikke grunnlaget som trengs for å kontrollere om beløpet var riktig.

Tre vanlige feil på leverandørfakturaer

Når en faktura ikke stemmer med innkjøpsordren, skyldes det nesten alltid ett av tre forhold. Hvert av dem har sin egen årsak og krever sin egen kontroll.

Prisavvik

Vanlige årsaker er at prislisten er oppdatert etter at bestillingen ble sendt, at leverandøren har lagt til et tillegg som ikke var med i tilbudet, at frakt, håndtering eller minstegebyr ikke var avtalt, eller at mengden passerte en kvantumsgrense og utløste en annen pris. Alt dette kan være forståelig fra leverandørens side. Spørsmålet er ikke om leverandøren prøver å lure noen, men om prisendringen er godkjent.

Mengdeavvik

Bestillingen gjaldt 40 enheter. Følgeseddelen viser at 38 ble levert, og fakturaen krever betaling for 42. Alle tre tallene er forskjellige, men fakturaen blir betalt mot bestillingen uten at noen ser på følgeseddelen. Derfor er det viktig med gode rutiner for registrering av varemottak. Hvis leveranser ikke registreres i samme system som bestillingen, mangler informasjonen som trengs for å oppdage avviket.

Uavtalte tillegg

«Oppstartsgebyr», «prosjektledelse» og «hastetillegg» er typiske eksempler. Noen ganger er tillegget berettiget, fordi omfanget faktisk har endret seg. Andre ganger har leverandøren lagt det til i god tro og regnet med at det ville bli akseptert, og ingen har reagert. Uavtalte tillegg er den vanskeligste feilen å oppdage, fordi kontrollen krever at noen legger merke til noe som ikke burde stå på fakturaen.

Hvorfor feilaktige fakturaer blir godkjent

De fleste virksomheter har en eller annen form for kontroll av faktura mot bestilling. I praksis foregår den ofte slik:

• Fakturaen kommer inn i regnskapsavdelingens innboks eller fakturasystem.
• Den som konterer fakturaen, finner fram bestillingen, enten som PDF i en delt mappe eller i et innkjøpssystem som er atskilt fra regnskapet.
• Totalbeløpene sammenlignes. De ligger nær hverandre, og fakturaen godkjennes for betaling.
• Fakturaen sendes til budsjettansvarlig for attestasjon. Budsjettansvarlig regner med at regnskapsavdelingen har kontrollert den.
• Betalingen går ut, og kontrollen regnes som utført.

Ved store volumer er det vanskelig å fange opp alle små avvik manuelt. Behandler du 200 leverandørfakturaer i måneden med 3–8 linjer hver, er det opptil 1 600 fakturalinjer der et avvik på et par prosent kan gå upåaktet hen. Det er krevende å kontrollere så mange linjer like grundig hver måned.

Det grunnleggende problemet er at fakturakontrollen i de fleste prosjektvirksomheter er en sammenligning mellom to dokumenter: fakturaen og bestillingen. Denne toveismatchingen kan avdekke pris- og mengdeavvik mellom bestilling og faktura. Men sammenligningen mangler en viktig kontroll: Hva ble faktisk levert?

Uten informasjon om varemottaket kan den som kontrollerer fakturaen, bare vurdere om den virker rimelig sammenlignet med det som ble bestilt. Spørsmålet som ville avdekket overbetalingene, er om fakturaen stemmer med både det som ble bestilt og det som faktisk ble mottatt.

Treveismatching gir bedre fakturakontroll

Metoden som løser dette, heter treveismatching. Før en faktura godkjennes for betaling, sammenlignes tre dokumenter: innkjøpsordren, varemottaket eller dokumentasjonen på utført leveranse, og leverandørfakturaen. Kontrollen gjøres linje for linje.

Treveismatching blir ofte presentert som en funksjon i et system for fakturaflyt, men det er først og fremst en kontrollrutine. Den kan gjennomføres manuelt eller med støtte fra programvare, og består av tre deler:

• Automatisk sammenligning. Programvare kan koble fakturaen til riktig innkjøpsordre og varemottak og sammenligne pris, antall og fakturalinjer.
• Identifisering av avvik. Linjer som ikke stemmer, blir markert før fakturaen går videre, slik at fakturaene som stemmer, kan godkjennes raskt.
• Manuell håndtering av unntak. Når det er avvik, må en person vurdere om fakturaen skal godkjennes, sendes tilbake til leverandøren eller eskaleres internt.

Automatiseringen gjør kontrollen raskere og mer pålitelig, mens beslutningen ved avvik fortsatt ligger hos den som godkjenner.

Dette påvirker hva du bør se etter i en løsning. Ser du på treveismatching som en funksjon, er det lett å kjøpe et system som har den på funksjonslisten og regne med at problemet er løst. Ser du på det som en kontrollrutine, etablerer du rutinen først, i systemet der bestillingene ligger, og velger verktøy som støtter den.

Med automatisk sammenligning kan tiden brukes på fakturaene som har avvik, i stedet for på dem som stemmer.

Her ligger forskjellen mellom raskere fakturaflyt og treveismatching som fast kontrollrutine. Et system for fakturaflyt tar utgangspunkt i fakturaen og forsøker å få den raskere fram til betaling. Treveismatching tar utgangspunkt i bestillingen og kontrollerer fakturaen mot den, og mot varemottaket, før betalingen går videre.

Hva du bør gjøre annerledes

Fire konkrete tiltak kan gi bedre fakturakontroll uten at virksomheten trenger å bytte økonomisystem.

Gjør treveismatching til standard, ikke unntak

Mange virksomheter bruker treveismatching bare på «vesentlige» fakturaer, for eksempel over et visst beløp, for enkelte prosjekttyper eller når den som konterer, har mistanke om feil. Men det er ofte de små avvikene under radaren som summerer seg. Treveismatching bør derfor være standard for alle fakturaer som er knyttet til en innkjøpsordre og en dokumentert leveranse. Fakturaer uten bestilling og varemottak, som faste strømregninger og forhåndsbetalte abonnementer, krever andre kontrollrutiner.

Kontroller hver fakturalinje, ikke bare totalbeløpet

Kontroll av totalbeløpet avdekker lite. To fakturaer kan ha samme totalbeløp med helt forskjellige linjer. Kontroller pris, antall og beskrivelse for hver linje. Hvis dagens kontroll ikke gjør det, er dette den viktigste enkeltendringen, og den bør gjøres før du velger verktøy.

Krev at kontrollen er utført før betaling godkjennes

Hvis fakturaer kan godkjennes for betaling før treveismatchingen er gjort, blir den ofte ikke gjort. Kontrollen må være et obligatorisk steg i godkjenningsprosessen, ikke noe som gjøres ved siden av. Sett opp prosessen slik at betaling bare kan godkjennes når kontrollen er registrert som fullført.

Hold leveranseinformasjonen samlet med bestillingen

Når bestillingen ligger i ett system, for eksempel innkjøpssystemet, prosjektverktøyet eller en delt mappe, og fakturaen i et annet, som regnskapet eller ERP-systemet, må kontrollen gjøres manuelt på tvers av systemene. Det er der rutinene ofte svikter. Bestilling, varemottak og faktura bør være tilgjengelige i samme visning når fakturaen godkjennes.

Når bestilling og faktura håndteres hver for seg

De fleste fakturaproblemer kan føres tilbake til hvordan innkjøpsordren lagres og gjøres tilgjengelig.

Hvis bestillingen er et statisk dokument, for eksempel en PDF sendt til leverandøren på e-post, arkivert og funnet fram igjen uker senere når fakturaen kommer, blir kontrollen tidkrevende fordi informasjonen må finnes og sammenlignes manuelt. Noen må finne bestillingen, sammenligne den med fakturaen, huske om noe ble endret muntlig etter at bestillingen ble sendt, og vurdere om avviket kan aksepteres.

Hvis bestillingen derimot er registrert i et system, knyttet til prosjektbudsjettet, synlig for prosjektteamet og med godkjenninger og endringer logget, blir kontrollen en enkel sammenligning side om side. Avvik blir tydelige, og den som godkjenner, ser hva som ble avtalt og når.

Problemet ligger altså ofte i hvordan bestillingene håndteres, like mye som i fakturaverktøyet. Kontrollen blir vanskelig når bestillingen lagres som et enkelt dokument, i stedet for å inngå i en oppdatert oversikt over prosjektets forpliktede kostnader.

Når det lønner seg å automatisere fakturakontrollen

Ved lavt volum og enkle innkjøp kan manuell kontroll være tilstrekkelig. Sender du noen titalls bestillinger i måneden, har små prosjekter der den som bestiller også kontrollerer fakturaene, og har tid til å kontrollere hver linje, vil gode manuelle rutiner fange opp de fleste feil.

Det er særlig tre situasjoner der et eget system for fakturakontroll kan være nyttig:

1. Når volumet blir for stort til at manuell kontroll er pålitelig. Med mer enn rundt 100 fakturaer i måneden med flere linjer hver, blir manuell kontroll vanskelig å gjennomføre like grundig hver gang. Her kan programvaren sammenligne de tre dokumentene automatisk, markere avvikene og samle alt i én visning, slik at den som kontrollerer, kan konsentrere seg om fakturaene som ikke stemmer.
2. Når det er mange prosjekter og mange budsjettansvarlige. Fakturaene må kontrolleres mot riktig bestilling, belastes riktig prosjektbudsjett og godkjennes av riktige personer, og dette varierer fra prosjekt til prosjekt. Manuell koordinering blir fort uoversiktlig. Her er programvarens viktigste oppgave å sende fakturaene til riktig sted.
3. Når leverandører fakturerer uregelmessig. Langvarige prosjekter, tilbakehold og flere fakturaer mot samme bestilling gjør at kontrollen ikke lenger er én faktura mot én bestilling. Den må ta hensyn til løpende summer, delleveranser og endringer. Programvaren kan holde oversikt over hva som er fakturert, mottatt og betalt mot den opprinnelige bestillingen.

I alle tre tilfellene får du mindre manuelt kontrollarbeid, bedre oversikt og en tydeligere arbeidsflyt. Programvaren tar seg av sammenligningen og viser avvikene, mens vurderingen av om et avvik er akseptabelt, ligger hos den som godkjenner. Når beslutningen dokumenteres i systemet, blir det også enklere å se i etterkant hva som ble godkjent, og hvorfor.

Hva feilbetalinger faktisk kan koste

Det er lett å måle kostnaden ved feilbetalinger som selve overbetalingen. Leverandøren fakturerte 84 000 kroner i stedet for 80 000, og tapet er 4 000 kroner. Skjer det med noen få fakturaer i året, virker risikoen håndterbar. Men den reelle kostnaden er større.

Selv om den direkte overbetalingen bare er noen tusen kroner i måneden, kan den samlede kostnaden av oppfølging, leverandørforhold, svakere datagrunnlag og bundet kapital fort komme opp i flere hundre tusen kroner i året. Få virksomheter regner den ut, fordi kostnadene er spredt på flere avdelinger og ingen har ansvar for helheten.

Hvordan dette henger sammen med kostnadskontroll i prosjekter

Å unngå feilbetalinger er en del av et større behov: å følge opp forpliktede kostnader løpende. Hvis du først ser kostnaden når fakturaen kommer, er det meste av handlingsrommet borte. Når fakturaen ligger i regnskapsavdelingens innboks, ble beslutningen bak den tatt flere uker tidligere.

Ved å registrere kostnadsforpliktelsen når bestillingen godkjennes, og ikke når fakturaen kommer, legger du grunnlaget for treveismatching. Når bestillingen ligger i et system som behandler den som en forpliktelse mot prosjektbudsjettet, kan varemottak og faktura kontrolleres mot den med full oversikt.

Det er også slik CostTracker fungerer. Innkjøpsordren og varemottaket ligger i systemet før fakturaen kommer. Mottas fakturaen direkte i CostTracker, leses leverandør, beløp og fakturalinjer automatisk, og systemet foreslår riktig innkjøpsordre. Mottas den i regnskapssystemet, hentes transaksjonen derfra og matches mot bestilling og levering. Den som kontrollerer, slipper å lete på tvers av systemer og kan bruke tiden på avvikene.

Treveismatching og oppfølging av forpliktede kostnader er dermed to sider av samme rutine. Den ene brukes når bestillingen godkjennes, den andre når fakturaen kommer, og begge forutsetter at innkjøpsordrene registreres som forpliktelser mot budsjettet.

Du trenger ikke bygge om hele fakturaprosessen for å få dette til. Det viktigste er å samle de tre dokumentene i én visning og gjøre kontrollen til et obligatorisk steg før betaling godkjennes. Valget av programvare bør følge av hvordan kontrollen skal gjøres.