Når de fleste restauratører hører “automatiseret fakturabehandling,” forestiller de sig en scanner, der erstatter en dataindtaster. Billedet er en PDF, der lander i en indbakke, bliver aflæst af software og dukker op i regnskabssystemet uden at nogen behøver at indtaste et leverandørnavn eller et totalbeløb i hånden. Det billede er korrekt, men det beskriver den mindst værdifulde del af, hvad automatiseret fakturabehandling reelt bør give en restaurant.
Den egentlige værdi af automatiseret fakturabehandling på en restaurant ligger i, hvad der sker med linjeniveaudata, efter det er trukket ud. Hvert kilogram, hver enhedspris og hver varekode på enhver faktura bliver et live input til opskriftsomkostningerne. Samme dag en leverandør hæver prisen på olivenolie med tolv procent, afspejler alle opskrifter, der bruger olivenolie, den nye pris. Det er forskellen på et OCR-værktøj og et system, der faktisk flytter margin.
Hvad en faktura egentlig indeholder
En leverandørfaktura er ikke ét enkelt stykke information. Det er et lagdelt dokument, og hvert lag bærer forskellig værdi for driften.
Øverst sidder headerdata: leverandørnavn, fakturanummer, dato, betalingsbetingelser og totalbeløb. Det er de oplysninger, bogholderiet bruger til at registrere forpligtelsen og betale fakturaen til tiden. Det er det lag, de fleste restauratører kender, fordi det er det lag, de gennemgår, når de godkender betalinger.
Under det sidder linjeposterne, som bærer det driftsmæssige signal. Hver linje er en specifik ingrediens eller et produkt med sin egen måleenhed, modtaget mængde, enhedspris og linjetotal. En enkelt faktura fra en grøntleverandør kan indeholde tredive eller fyrre linjer, og hver enkelt er en selvstændig ingrediens med sin egen pris, der måske eller måske ikke stemmer overens med, hvad opskriftssystemet antager, at det koster.
Dertil kommer metadata, der strækker sig på tværs af begge lag: leveringsdato, leverandørkode per ingrediens, momshåndtering og eventuelle rabatter eller tillæg. Det er dette lag, der gør det muligt at knytte linjedata til specifikke leverandører, specifikke ingredienser og specifikke tidspunkter, og det er det, der gør trendanalyse mulig.
Værdien af ethvert fakturabehandlingssystem afhænger fuldstændig af, hvilke af disse lag det fanger.
Hvad der sker, når du kun trækker totalen ud
Den simpleste form for fakturaautomatisering læser headeren og totalen, lægger begge i regnskabet og stopper der. Det er niveauet, de fleste generiske regnskabsautomatiseringsværktøjer til restauranter arbejder på, og det er reelt nyttigt for bogholderen. Fakturaen kodes til den rigtige udgiftskonto, betalingen planlægges, og månedsafslutningen kører rent.
Hvad det ikke gør, er at røre ved vareomkostningerne. Systemet ved, at der blev brugt 2.400 euro hos én leverandør i sidste uge, men det ved ikke, om prisen på oksekød steg, om bestillingen af madolie fordobledes i volumen, eller om en enkelt linje på fakturaen indeholdt en prisstigning, der stille og roligt lagde tusindvis af euros ekstra eksponering ud over menukortet.
Margintab fra leverandørprisudvikling viser sig ikke i totaler. Det gemmer sig i linjeposter. Et system, der kun fanger headere, er fint til at betale regninger og ubrugeligt til at beskytte marginen, og det er det hul, de fleste restauratører ikke opdager, før de begynder at lede efter det.
Hvad der sker, når du trækker hver enkelt linje ud
Linjebaseret fakturabehandling læser hver linje på fakturaen som sin egen strukturerede post og fanger leverandørkode, mængde, måleenhed, enhedspris og dato som én struktureret post per ingrediens. Hver linje bliver et datapunkt mod den ingrediens, den repræsenterer.
Det første, dette åbner for, er prissammenligning. Enhedsprisen på dagens faktura sammenholdes med enhedsprisen på den forrige faktura fra samme leverandør for den samme ingrediens. Enhver bevægelse over en defineret grænseværdi dukker straks op, inden fakturaen godkendes til betaling. En stigning på 9 procent på kyllingebryst slipper ikke igennem, fordi den markeres ved modtagelse og ikke opdages uger senere under en varetælling.
Det andet, det åbner for, er aktuelle kostpriser per ingrediens. Alle ingredienser i systemet har en live pris, der afspejler den seneste faktura og ikke den pris, der sidst blev opdateret manuelt. Når prisen ændrer sig, ændres ingrediensposten, og alt, der beregnes nedstrøms fra den ingrediens, ændres med den.
Det tredje er forbrugsoverblik. Mængden på hver fakturalinje registreres, så systemet ved præcis, hvor meget af hver ingrediens der er købt i en given periode. Det tal kan afstemmes mod, hvad der er solgt, hvad der er talt op, og hvad der burde være brugt ifølge opskrifterne. Uden linjeniveaudata er ingen af de sammenligninger mulige.
Hvordan linjebaseret udtræk hænger sammen med opskriftsomkostninger
Her ophører leverandørfaktura-OCR med at være en regnskabsfunktion og begynder at være et marginværktøj.
Enhver opskrift på en restaurant er en liste over ingredienser med mængder. Opskriftens kostpris er summen af prisen på de ingredienser til deres aktuelle pris. Hvis ingredienserne er knyttet til live faktурadata, er opskriftsprisen aktuel per definition. Hvis de er knyttet til en manuelt vedligeholdt prisliste, er opskriftsprisen kun aktuel frem til, hvornår nogen sidst satte sig ned for at opdatere listen.
I et system, hvor linjebaserede fakturadata flyder direkte ind i opskrifterne, ser kæden sådan ud. Fakturaen ankommer. Linjeposterne trækkes ud og matches med ingredienser. De nye enhedspriser erstatter de tidligere enhedspriser i ingrediensposterne. Alle opskrifter, der indeholder nogen af de pågældende ingredienser, genberegnes. De nye opskriftspriser kaskaderer videre til eventuelle varekostprocentgrænser, menumarginberegninger og teoretiske vareforbrug, der afhænger af dem. Alt dette sker samme dag, uden at nogen behøver at huske at gøre det.
Kaskaden betyder mest for restauranter med præfabrikerede baser og komponenter. En enkelt ingrediens kan indgå i en sauce, som indgår i tre menupunkter, som indgår i en gruppebaseret menuanalyse. En manuel opdatering af opskriftsomkostninger ville kræve, at man sporede den kæde i hånden for hver prisændring på hver ingrediens. Automatiseret fakturabehandling udfører sporingen én gang i softwaren, i det øjeblik den nye pris ankommer.
Hvad der går tabt, når dette gøres manuelt
Prisen på en manuel opskriftskostproces måles sjældent direkte, men den er synlig tre steder.
Det første er prisskifteblindhed. I en manuel proces afspejler opskriftsomkostningerne, hvad der var sandt, da nogen sidst opdaterede prislisten. Var det for fire uger siden, er hvert margental, restauranten har kigget på siden da, beregnet på grundlag af fire uger gammelt prisgrundlag. Leverandørstigninger, der er sket i mellemtiden, er usynlige for driften, indtil prislisten røres igen.
Det andet er opskriftsdrift. Enhver opskrift, der afhænger af en forældet ingredienskostpris, er selv forældet. Kaskaden forværres. En prisstigning på 5 procent på én ingrediens kan flytte kostprisen på et dusin opskrifter med en til to procent hver, og de små forskydninger lægger sig oven på hinanden til et meningsfuldt hul mellem teoretisk og faktisk vareforbrug, som ingen kan spore fuldt ud.
Det tredje er afvigelsesforøgelse. Når lagerafvigelse beregnes fra en varetælling, er sammenligningen mellem, hvad der faktisk er brugt, og hvad der burde være brugt ifølge opskrifterne. Hvis opskriftspriserne er forkerte, er afvigelsestallet forkert, og restauratøren ender med enten at jagte problemer, der ikke findes, eller med at overse problemer, der gør.
Hvordan “fra faktura til indsigt” ser ud i praksis
På en restaurant, der kører automatiseret fakturabehandling på linjeniveau, ser arbejdsgangen ordinær ud udefra. Fakturaer ankommer i regnskabssystemet. Betalingskørsler afvikles efter plan. Ingen taster leverandørnavne ind i regneark.
Hvad der er anderledes, sidder underneden. Hver morgen er de foregående dages fakturaer allerede behandlet til ingrediensniveaudata og matchet mod de eksisterende kostposter. Enhver prisbevægelse over en defineret grænseværdi er dukket op som et flag, restauratøren kan gennemgå. Alle opskrifter, der er påvirket af ændringerne, er genberegnet, og varekostprocentsystemet afspejler den nye virkelighed, inden nogen åbner det.
Når afvigelser dukker op ved udgangen af en optællingsperiode, kan de spores rent. Opskriftsomkostningerne var aktuelle, fakturaoplysningerne var fuldstændige, og uoverensstemmelsen er mellem, hvad der er solgt, og hvad der er talt op, ikke mellem gårsdagens prisgrundlag og forrige kvartals. Undersøgelsen går direkte til overportering, spild eller udefinerede salg frem for at sande til i spørgsmålet om, hvorvidt inputtene overhovedet var pålidelige.
Det er det, automatiseret fakturabehandling til restauranter er sat i verden for at gøre. Besparelsen på dataindtastning er reel, og den primære værdi er, at alle opskrifter på restauranten afspejler, hvad virksomheden faktisk betaler for ingredienser i dag, uden et manuelt trin imellem leverandørprisændringen og margentallet, der opdateres.
Hvornår sidst afspejlede dine opskriftsomkostninger, hvad der ankom med denne uges fakturaer?