Flowchart for procure-to-pay (P2P): fra behov til betaling
Flowchart for procure-to-pay-processen fra identificeret behov til betalt leverandør: indkøbsanmodning, budget- og fuldmagtsgodkendelse, aftalekontrol, indkøbsordre, varemodtagelse, trevejsmatch, fakturaer uden ordre og betalingskørslen.
Hvad er flowchart for procure-to-pay (p2p): fra behov til betaling?
Procure-to-pay er den proces, næsten alle organisationer kører, og næsten ingen ejer. Indkøb ejer ordren, den budgetansvarlige ejer godkendelsen, lageret ejer modtagelsen, og kreditor ejer fakturaen, og hver af de fire bliver målt på sit eget stykke, så hver af dem er effektiv, mens forløbet som helhed er langsomt. Skaden lander altid i den fjerne ende. En faktura kan ikke matches, fordi ingen registrerede modtagelsen, eller fordi ordren blev oprettet, efter varerne kom, eller fordi prisen på ordren aldrig var den, der var aftalt. Kreditor bærer så konsekvensen af beslutninger truffet uger tidligere af folk, som aldrig kommer til at se afklaringskøen, og den løsning, der bliver taget i brug, er en efterfølgende indkøbsordre: den rydder puklen og ødelægger registreringen af forpligtelser i samme bevægelse. Ingen måler fra anmodning til betaling som ét tal, så den samlede gennemløbstid er usynlig selv for dem, der klager over den, og leverandøren, der rykker for sine penge, er den eneste part med udsyn til det hele.
Denne side er det operationelle forløb fra ende til anden, og den er med vilje sammenføjningen frem for detaljen. Hvert enkelt trin har allerede sin egen side: den interne vej, en forespørgsel tager, før nogen ordre findes, ligger på /da/templates/indkoebsanmodning-proces, oprettelse og udstedelse af ordren på /da/templates/indkoebsordre-proces, rampen på /da/templates/varemodtagelse-proces, den enkelte fakturas vej på /da/templates/fakturagodkendelse-proces, og hele kreditorfunktionen inklusive betalingskørsler og periodeafslutning på /da/templates/kreditorproces. Har I kun brug for ét trin, så gå til det trins egen side: dybden dér er større end noget her. Sourcingstrategi, udbud, evaluering og leverandørsamarbejdet bagefter hører til på /da/templates/indkoebsproces, som starter fra det samme identificerede behov, men drejer til venstre ud i markedet frem for ind i regnskabet. Og er det, I reelt har brug for, den kontrolorienterede udgave af det samme forløb til revision af interne kontroller (SOX, ICFR eller en ekstern gennemgang) er /da/templates/indkoeb-til-betaling-p2p-procesflow skrevet til det publikum. Dette diagram er til den, der har fået til opgave at få forløbet til at fungere.
Tre ting, som skrevne P2P-procedurer lader være underforstået, er her tegnet som grene. Godkendelsen er delt i to, fordi 'Er der budget på omkostningsstedet?' og 'Over fuldmagtsgrænsen?' er to forskellige spørgsmål med hver sin ejer (budgettet siger, at pengene var planlagt, fuldmagten siger, at netop denne person må forpligte organisationen), og at slå dem sammen er præcis, hvordan en ordre med budgetdækning bliver skrevet under af en, der ikke må skrive under. Matchet er delt i to af samme grund. 'Er vare- eller ydelsesmodtagelse registreret?' stilles før 'Trevejsmatch inden for tolerance?', fordi en manglende modtagelse går tilbage til rekvirenten, mens en prisafvigelse er en samtale med leverandøren, og en kø, der blander de to, bliver aldrig arbejdet ned. Tolerancen er en grænse og ikke en beståelsesgrænse: det eneste sted i forløbet, hvor en organisation i tal skriver, hvor stor en afvigelse den betaler uden at spørge, og skriver man den ikke, bruger hver bogholder sin egen. Og vejen for fakturaer uden ordre er tegnet frem for benægtet. 'Er der ordrereference?' sender en faktura uden reference videre til 'Efterfølgende ordre godkendt?' i den budgetansvarliges bane, og derfra kommer enten en godkendt ordre, der løber ind i matchet igen, eller enden 'Faktura returneret ubetalt, ingen ordre', for et princip om ingen ordre, ingen betaling uden en undtagelsesvej er ikke et princip, det er en kø.
Hvad dette flowchart dækker
I denne skabelon
- Seks swimlanes (Rekvirent, Budgetansvarlig, Indkøb, Leverandør, Kreditor og Økonomi) hen over seks faser: Indkøbsanmodning, Godkendelse, Sourcing og ordre, Modtagelse og faktura, Match og afklaring samt Betaling og rapportering
- En todelt godkendelse: 'Er der budget på omkostningsstedet?' afviser eller udskyder anmodningen på et Nej, og 'Over fuldmagtsgrænsen?' ruter alt over underskriverens grænse gennem 'Indhent godkendelse på højere niveau' i Økonomi-banen, før Indkøb overhovedet ser det
- Skillevejen mellem aftaletræk og marked ved 'Findes der en aftale eller rammeaftale?', hvor Ja går direkte til 'Udsted indkøbsordren til leverandøren', mens Nej først lægger en tur ind over 'Kør et sourcingforløb og tildel'
- Den kæde af forpligtelser, der overhovedet gør et match muligt: indkøbsordren, 'Lever varen eller udfør ydelsen', 'Registrer modtagelse på indkøbsordren' og 'Send fakturaen til betaling', hver især i banen hos den, der faktisk gør det
- Matchet tegnet som to blokke frem for én: 'Er vare- eller ydelsesmodtagelse registreret?' sender en blokeret faktura tilbage til 'Registrer modtagelse på indkøbsordren' i rekvirentens bane, mens 'Trevejsmatch inden for tolerance?' sender en afvigelse videre til 'Opret afklaring og rejs sagen', leverandøren retter fakturaen eller udsteder en kreditnota, og 'Er afklaringen løst?' enten kører matchet igen eller lader forløbet ende ved 'Tvist håndteres efter kontrakten'
- Vejen for fakturaer uden ordre og den hale, ingen tegner: 'Efterfølgende ordre godkendt?' fører enten tilbage i matchet eller ender ved 'Faktura returneret ubetalt, ingen ordre', mens den rene vej løber gennem 'Bogfør den matchede faktura til betaling', 'Frigiv betalingskørslen til leverandøren' og 'Opdater leverandør- og forbrugsdata' frem til 'Forløb lukket og forbrug rapporteret'
Hvornår du skal bruge skabelonen
- I skal skrive eller opdatere en indkøbspolitik og har brug for ét diagram, der viser hele forløbet, frem for fire trin-dokumenter, der hver især stopper ved en overlevering og modsiger hinanden om, hvem der tager det næste stykke
- Jeres afklaringskø hos kreditor vokser, og I har brug for at vise, at de fleste årsager ligger opstrøms (i manglende modtagelser og i ordrer, der er oprettet bagefter) og ikke hos kreditorteamet
- I indfører eller håndhæver et princip om ingen ordre, ingen betaling og skal have undtagelsesvejen, de undtagne kategorier og godkenderen på plads, før den første faktura bliver returneret
- I opsætter eller migrerer et ERP- eller P2P-system, og tolerancetal, godkendelsesgrænser, regler for modtagelsesregistrering og årsagskoder for afklaringer skal afklares som proces, før nogen rører et opsætningsbillede
- I onboarder rekvirenter, budgetansvarlige eller et nyt shared service-center og vil kunne undervise i hele forløbet, dets to afvisningsveje og dets overlevering til tvisthåndtering ud fra ét billede
Sådan fungerer det
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.
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.
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.
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.
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.
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.