Flowchart for procure-to-pay (P2P) — fra behov til betaling

Sådan fungerer det

1. Omdøb banerne, så de passer til jeres organisation

   Erstat Rekvirent, Budgetansvarlig, Indkøb, Leverandør, Kreditor og Økonomi med de roller, I reelt har. Hold kun kreditor adskilt fra Økonomi, hvis det er forskellige personer, der bogfører fakturaer og frigiver betalingskørsler; er det den samme, så slå banerne sammen frem for at lade en bane stå, der aldrig gør noget. Ligger fakturaarbejdet i et shared service-center, så skriv det. Er varemodtagelsen et andet team end rekvirenten, så tilføj en lagerbane, og flyt modtagelsestrinnet derover.

2. Skriv begge godkendelsesgrænser som tal

   'Er der budget på omkostningsstedet?' og 'Over fuldmagtsgrænsen?' er tomme, indtil I hænger tal på dem. Udgiv fuldmagtsmatrixen som beløb pr. rolle, skriv, om testen er ordrens værdi eller kontraktens samlede værdi over hele løbetiden, og beslut, hvordan allerede disponerede beløb på samme budgetlinje tæller med. Skriv derefter ned, hvad der sker med et behov, der deles op i to ordrer under grænsen, for opdeling for at slippe for den næste underskrift er den hyppigste måde, kontrollen bliver sat ud af kraft.

3. Fastlæg tolerancen for trevejsmatch

   Læg jeres egne tal på 'Trevejsmatch inden for tolerance?': en procentsats og et absolut loft på prisen, hvor den laveste gælder, og en strammere tolerance på mængde end på pris. Beslut særskilt, hvordan fragt, told, afrunding og valutakursforskelle behandles, for de bryder flere match end varerne nogensinde gør. Skriv, hvem der må tilsidesætte et fejlet match, og registrer hver eneste tilsidesættelse — en tilsidesættelse, der ikke er logget, kan ikke skelnes fra slet ingen kontrol.

4. Definer modtagelsesregistrering for ydelser, ikke kun for varer

   'Er vare- eller ydelsesmodtagelse registreret?' er den grænse, der fylder de fleste afklaringskøer: varer får en modtagelse på rampen, ydelser får ofte ingenting. Navngiv den, der bekræfter, at en ydelse er leveret — normalt rekvirenten, der bad om den, ikke indkøberen, der lagde ordren — og sæt fristen ud fra ordrens forventede afslutningsdato. For milepæls- og abonnementskontrakter beslutter I, om modtagelse sker pr. milepæl eller pr. periode, og læg åbne ordrer uden registreret modtagelse på nogens rapport, så der bliver rykket for dem inden månedsafslutning.

5. Aftal undtagelsesvejen for fakturaer uden ordre og dens undtagelser

   'Efterfølgende ordre godkendt?' er det, der gør ingen ordre, ingen betaling til noget, man kan leve med. Beslut, hvilke kategorier der reelt er undtaget, for eksempel forsyning, husleje, ejendomsskatter, lovpligtige gebyrer og visse faste honorarer, og luk dem ude allerede ved 'Er der ordrereference?' frem for at diskutere sag for sag. Navngiv derefter godkenderen — den budgetansvarlige, der ville have godkendt den oprindelige anmodning, aldrig kreditor — og rapportér efterfølgende ordrer hver måned pr. afdeling, så undtagelsen forbliver en undtagelse.

6. Gå den igennem med dem, der gør arbejdet, og udgiv en version

   Tag det færdige diagram med til en rekvirent, en budgetansvarlig, en indkøber, en kreditorbogholder og den, der frigiver betalingskørslen, og ret det til det, der faktisk sker, frem for det, politikken siger. Spørg hver af dem, hvilket trin de stille og roligt er holdt op med at gøre. Bliv enige om de målepunkter, der kommer ud af 'Opdater leverandør- og forbrugsdata', og udgiv så den revision, mens I beholder de tidligere, så enhver, der åbner diagrammet senere, kan se, hvilken version de læser.

Ofte stillede spørgsmål

Hvilke trin består en procure-to-pay-proces (P2P) af?

Et komplet forløb er: identificer behovet; opret en indkøbsanmodning med specifikation og kontering; bekræft, at der er budget; hold værdien op mod fuldmagtsmatrixen, og eskaler alt over grænsen; undersøg, om en godkendt aftale eller rammeaftale allerede dækker behovet, og gå i markedet, hvis ikke; udsted indkøbsordren til leverandøren; modtag varen eller ydelsen, og registrer modtagelsen på ordren; tag leverandørfakturaen ind, og kontroller, at den henviser til en gyldig indkøbsordre, og at der er registreret en modtagelse på den; kør trevejsmatchet mellem ordre, modtagelse og faktura; løs afvigelser uden for tolerance som afklaringer med leverandøren; bogfør den matchede faktura; frigiv den i en betalingskørsel; og opdater leverandør- og forbrugsdata, så næste sourcingrunde har noget at bygge på. Listen er ikke det svære. Det, der bryder forløbet, er den modtagelse, ingen registrerer, og den faktura, der ankommer uden en ordre bag sig.

Hvad er et trevejsmatch, og hvilken tolerance skal vi sætte?

Et trevejsmatch betaler kun en faktura, hvor indkøbsordren, varemodtagelsen og fakturaen er enige om vare, mængde og pris. Definitionen er den nemme del; tallene er arbejdet. Match til sidste øre ville sende næsten hver eneste faktura i kø, så sæt både en procentsats og et absolut loft på prisafvigelsen, og brug den, der er lavest, og hold mængden i en strammere tolerance end prisen — en lille prisforskel er en diskussion om afrunding, en lille mængdeforskel er varer, der mangler. Skriv særskilte regler for fragt, told, afrunding og valutakursforskelle, som bryder flere match end varerne nogensinde gør. Beslut derefter, hvad der sker med ydelser, hvor der ofte slet ikke er noget tælleligt at modtage, og hvor organisationer falder tilbage på et tovejsmatch mod ordren eller på en milepælsbekræftelse fra rekvirenten. Udgiv, hvem der må tilsidesætte et fejlet match, og log hver tilsidesættelse: en tolerance, der ikke er skrevet ned, bruges forskelligt af hver bogholder, og en tilsidesættelse, der ikke er logget, betyder, at kontrollen ikke kan dokumenteres — heller ikke når den virkede.

Hvad betyder ingen ordre, ingen betaling i praksis?

Det betyder, at en faktura, der ikke henviser til en gyldig indkøbsordre, ikke bliver betalt, men returneret til leverandøren. Begrundelsen er, at der uden en ordre hverken er en aftalt pris, en forpligtelse registreret i regnskabet eller dokumentation for, at nogen med bemyndigelse godkendte forbruget, før det blev pådraget. I praksis fejler et princip uden undtagelser, medmindre to ting er på plads først. Der skal være en udgivet liste over undtagne kategorier — typisk forsyning, husleje, ejendomsskatter, lovpligtige gebyrer og visse faste honorarer — som lukkes ude ved grænsen frem for at blive diskuteret enkeltvis. Og der skal være en defineret undtagelsesvej for alt det øvrige: i dette diagram går en faktura uden reference til 'Efterfølgende ordre godkendt?' i den budgetansvarliges bane, så den, der burde have oprettet anmodningen, selv skal godkende det bagefter, det bliver logget, og det bliver rapporteret pr. afdeling. Uden den vej opretter kreditor stille og roligt de efterfølgende ordrer selv, og princippet bliver til papirarbejde.

Hvordan adskiller siden sig fra skabelonen med P2P-procesflowet til ERP?

Det er det samme forløb skrevet til to forskellige læsere. Skabelonen for procure-to-pay-procesflow på /da/templates/indkoeb-til-betaling-p2p-procesflow rammer forløbet ind som et sæt kontrolpunkter til revision af interne kontroller over den finansielle rapportering: procesejer, kildesystem, godkendelsestrin og dokumentation ved hvert trin, i den form en ekstern revisor går igennem i en kontroltest. Denne side er det operationelle flow for dem, der kører det — seks swimlanes, den todelte godkendelse, tolerancebeslutningen, afklaringsløkken og vejen for fakturaer uden ordre — og den er skrevet til at blive rettet til jeres egne grænser frem for at blive lagt frem for en revisor, som den er. Der er også en forskel i omfang i begge ender: dette diagram starter ved det identificerede behov og slutter ved forbrugsrapporten, mens den kontrolorienterede udgave koncentrerer sig om spændet fra anmodning til betaling, hvor regnskabspåstandene ligger. Brug den til revisionsmappen og denne til processen.

Skal vi bruge denne eller de enkelte flowcharts for indkøbsordre og faktura?

Brug denne, når problemet går på tværs af trin, og de enkelte trinsider, når det ikke gør. Dette diagram presser hvert trin sammen til de skridt, det næste trin afhænger af, så det kan vise hele forløbet på én side — og det er præcis, hvad I har brug for, når modtagelser mangler, når fakturaer ankommer uden ordre, eller når ingen kan sige, hvor lang tid der reelt går fra anmodning til betaling. Det er med vilje mere overfladisk end trinsiderne. Skal I lave godkendelsesgrænser og kontering på anmodninger om, går /da/templates/indkoebsanmodning-proces meget længere. Til oprettelse og udstedelse af ordren: /da/templates/indkoebsordre-proces. Til rampen, afvigelser og fragtskader: /da/templates/varemodtagelse-proces. Til den enkelte fakturas vej inklusive dubletkontrol og kontering: /da/templates/fakturagodkendelse-proces. Til betalingskørslen, afstemning af leverandørkontoudtog og hensættelser ved periodeafslutning: /da/templates/kreditorproces. De fleste ender med begge dele: denne i politikken, trindiagrammerne i arbejdsinstruktionerne.