Når de fleste operatører hører «automatisert fakturabehandling», ser de for seg en skanner som erstatter en dataregistreringsjobb. Bildet er en PDF som ankommer en innboks, leses av programvare og dukker opp i regnskapssystemet uten at noen trenger å taste inn leverandørnavn eller totalsummer på nytt. Det bildet stemmer, men det beskriver den minst verdifulle delen av det automatisert fakturabehandling faktisk kan gjøre for en restaurant.
Den virkelige verdien sitter i hva som skjer med linjenivå-dataene etter at de er hentet ut. Hvert kilogram, hver enhetspris, hver leverandørkode på hver faktura blir et levende innspill i oppskriftskostnaden. Samme dag en leverandør hever prisen på olivenolje med tolv prosent, reflekterer alle oppskrifter som bruker olivenolje den nye kostnaden. Det er forskjellen på et OCR-verktøy og et system som faktisk påvirker marginen.
Hva en faktura egentlig inneholder
En leverandørfaktura er ikke én enkelt informasjon. Det er et lagdelt dokument, og hvert lag bærer ulik verdi for driften.
Øverst sitter header-dataene: leverandørnavn, fakturanummer, dato, betalingsbetingelser og totalbeløp. Dette er informasjonen regnskapet trenger for å registrere forpliktelsen og betale regningen i tide. Det er laget de fleste operatører kjenner best, fordi det er det de ser gjennom når de godkjenner betalinger.
Under der sitter linjepostene, som bærer det operative signalet. Hver linje er en konkret ingrediens eller et produkt med sin egen måleenhet, mottatt mengde, enhetspris og linjesum. En enkelt faktura fra en råvareleverandør kan inneholde tretti til førti linjer, der hver linje er en separat ingrediens med en pris som kanskje eller kanskje ikke stemmer med det oppskriftssystemet tror det koster.
Så er det metadataene som strekker seg over begge lag, inkludert leveringsdato, leverandørkode per ingrediens, mva-behandling og eventuelle rabatter eller tillegg. Dette laget er det som gjør det mulig å knytte linjedataene tilbake til bestemte leverandører, bestemte ingredienser og bestemte tidspunkter, og det er det som gjør trendanalyse mulig.
Verdien av et fakturabehandlingssystem avhenger helt av hvilke av disse lagene det fanger opp.
Hva som skjer når du bare henter ut totalen
Den enkleste formen for fakturaautomatisering leser header og totalsum, sender begge til regnskapet og stopper der. Dette er nivået de fleste generiske regnskapsautomatiseringsverktøy for restauranter opererer på, og det er genuint nyttig for regnskapsansvarlig. Fakturaen kodes til riktig utgiftskonto, betalingen planlegges, og månedsavstemmingen går greit.
Det det ikke gjør, er å berøre varekostnadene. Systemet vet at det ble brukt 2 400 € hos én leverandør forrige uke, men det vet ikke om prisen på biff gikk opp, om bestillingen av matolje doblet seg i volum, eller om én enkelt linje på den fakturaen hadde en prisøkning som stille la til tusenvis av euro i eksponering på tvers av menyen.
Margintap fra leverandørprisdrift vises ikke i totalsummer. Det gjemmer seg i linjepostene. Et system som bare leser header er fint for å betale regninger, men ubrukelig for å beskytte marginen, og det er gapet de fleste operatører ikke oppdager at det finnes før de begynner å lete.
Hva som skjer når du henter ut hver enkelt linje
Linjepost-fakturabehandling leser hver linje på fakturaen som sin egen strukturerte post, og fanger opp leverandørkode, mengde, måleenhet, enhetspris og dato som én strukturert post per ingrediens. Hver linje blir et datapunkt mot ingrediensen den representerer.
Det første dette åpner for, er prissammenlikning. Enhetsprisen på dagens faktura sammenlignes med enhetsprisen på forrige faktura fra samme leverandør for samme ingrediens. Enhver bevegelse over en definert terskel dukker opp umiddelbart, før fakturaen er godkjent for betaling. En økning på 9 prosent på kyllingbryst slipper ikke gjennom, fordi den flagges ved mottak og ikke oppdages uker senere under en varetelling.
Det andre det åpner for, er gjeldende kostdata per ingrediens. Hver ingrediens i systemet har en levende kostnad som reflekterer siste faktura, ikke kostnaden fra sist noen manuelt oppdaterte den. Når prisene endrer seg, endres ingrediensposten, og alt som er beregnet nedstrøms fra den ingrediensen endrer seg med den.
Det tredje det åpner for, er forbrukssynlighet. Mengden på hver fakturalinje fanges opp, slik at systemet vet nøyaktig hvor mye av hver ingrediens som ble kjøpt inn i en gitt periode. Det tallet kan avstemmes mot hva som ble solgt, hva som ble talt opp, og hva som burde ha blitt brukt ifølge oppskriftene. Uten linjenivå-data er ingen av disse sammenligningene mulige.
Hvordan linjenivå-utvinning kobles til oppskriftskostnad
Her slutter leverandørfaktura-OCR å være en regnskapsfunksjon og begynner å bli et marginverktøy.
Hver oppskrift på en restaurant er en liste over ingredienser med mengder. Kostnaden for oppskriften er summen av kostnaden for de ingrediensene til gjeldende pris. Hvis ingrediensene er knyttet til levende fakturadata, er oppskriftskostnaden per definisjon oppdatert. Hvis de er knyttet til en manuelt vedlikeholdt prisliste, er oppskriftskostnaden bare oppdatert så nylig som sist noen satte seg ned for å oppdatere listen.
I et system der linjenivå-fakturadata flyter direkte inn i oppskrifter, ser kjeden slik ut. Fakturaen ankommer. Linjepostene hentes ut og matches mot ingredienser. De nye enhetsprisene erstatter de forrige enhetsprisene på ingredienspostene. Enhver oppskrift som inneholder noen av disse ingrediensene får regnet ut ny kostnad. De nye oppskriftskostnadene kaskaderer inn i varekostprosent-referansene, marginberegningene for menyen og de teoretiske varekostnadstallene som avhenger av dem. Alt dette skjer samme dag, uten at noen trenger å huske å gjøre det.
Kaskaden betyr mest for restauranter med forhåndsproduserte baser og komponenter. En enkelt ingrediens kan inngå i en saus, som inngår i tre menyretter, som igjen inngår i en gruppenivå-menyanalyse. En manuell oppdatering av oppskriftskostnad ville kreve at man sporer den kjeden for hånd for hver prisendring på hver ingrediens. Automatisert fakturabehandling gjør sporingen én gang, i programvare, i det øyeblikket den nye prisen ankommer.
Hva som går tapt når dette gjøres manuelt
Kostnaden ved en manuell oppskriftskostnadsprosess måles sjelden direkte, men den vises tre steder.
Det første er prisendringsblindheten. I en manuell prosess reflekterer oppskriftskostnadene det som var sant sist noen oppdaterte prislisten. Hvis det var for fire uker siden, er hvert margintal restauranten har sett siden da beregnet mot fire uker gammel prising. Leverandørøkninger som skjedde i mellomtiden er usynlige for driften inntil prislisten berøres igjen.
Det andre er oppskriftsdrift. Enhver oppskrift som er avhengig av en utdatert ingredienskostnad er selv utdatert. Kaskaden forsterkes. En prisøkning på 5 prosent på én ingrediens kan forskyve kostnaden på et dusin oppskrifter med en prosent eller to hver, og de små forskyvningene summerer seg til et meningsfylt gap mellom teoretisk og faktisk varekostnad som ingen kan spore fullt ut.
Det tredje er avviksskjevhet. Når lageravvik beregnes fra en varetelling, er sammenligningen mellom hva som faktisk ble brukt og hva som burde ha blitt brukt ifølge oppskriftene. Hvis oppskriftskostnadene er feil, er avvikstallet feil, og operatøren ender opp med å jage problemer som ikke finnes, eller overse problemer som faktisk er der.
Hva «fra faktura til innsikt» faktisk ser ut som i drift
På en restaurant som kjører automatisert fakturabehandling på linjenivå, ser arbeidsflyten helt ordinær ut utenfra. Fakturaer ankommer regnskapssystemet. Betalinger går ut etter planen. Ingen taster leverandørnavn inn i regneark.
Det som er annerledes, sitter under overflaten. Hver morgen er forrige dags fakturaer allerede analysert ned til ingrediensnivå og matchet mot eksisterende kostposter. Enhver prisbevegelse over en definert terskel har dukket opp som et flagg operatøren kan gjennomgå. Enhver oppskrift berørt av disse endringene er regnet om på nytt, og varekostnadssporingssystemet reflekterer den nye virkeligheten før noen åpner det.
Når avvik dukker opp på slutten av en telleperiode, kan de spores rent. Oppskriftskostnadene var oppdaterte, fakturadataene var komplette, og avviket er mellom hva som ble solgt og hva som ble talt opp, ikke mellom gårsdagens prissetting og fjorårets. Undersøkelsen går rett til porsjonering, svinn eller udefinert salg, i stedet for å vikle seg inn i om tallgrunnlaget var til å stole på.
Det er det automatisert fakturabehandling for restauranter er ment å gjøre. Besparelsene på dataregistrering er reelle, og den primære verdien er at enhver oppskrift på restauranten reflekterer hva driften faktisk betaler for ingredienser i dag, uten noe manuelt steg mellom at leverandørprisen endrer seg og at margintallet oppdateres.
Når ble egentlig oppskriftskostnadene dine sist oppdatert til å gjenspeile det som kom inn på ukens fakturaer?