Vad rabatthantering behöver spåra mellan system
Ett rabattavtal är enkelt att beskriva men krångligt att beräkna, eftersom varje del som beräkningen kräver finns på olika ställen. Fem delar måste sammanföras, och endast en av dem är från början läsbar data.
- Avtalsvillkoren: de tröskelvärden, procentsatser, nivåer och kvalificeringsperioder som förhandlats fram, vilka vanligtvis finns som ett avtalsdokument snarare än som strukturerade fält
- Kvalificerande transaktioner: vilka inköp eller försäljningar som räknas mot en tröskel, baserat på regler för produktgrupp, kund och datum
- Framsteg mot tröskelvärde: hur nära ett konto är nästa nivå, den siffra säljteamet behöver mest men ser minst av
- Periodiseringen: det belopp som ekonomiavdelningen redovisar i den aktuella perioden för rabatt som förväntas tjänas in, bokfört innan pengarna har inkommit
- Avräkning: det anspråk som ställts, kreditnotan som tagits emot och kontrollen av att betalningen stämmer överens med anspråket
Endast den andra punkten är okomplicerad, eftersom transaktionsdata redan är strukturerad och finns i affärssystemet. Den första är ett dokument, den tredje är en beräkning som nästan ingen kör kontinuerligt, och de två sista är beroende av båda. Det är därför rabattsiffran som ekonomiavdelningen rapporterar mitt i en period nästan alltid är en uppskattning.
Varför förblir beräkningar för rabatthantering uppskattningar?
Villkoren kommer som text snarare än som data. Ett rabattavtal är ett förhandlat dokument med villkor skrivna i meningar. Någon måste omvandla det till en regel som körs mot transaktionsposter, och göra om det varje gång avtalet förnyas.
Trappstegsbaserade avtal gör att den korrekta summan förblir okänd fram till periodens slut. Många betalar en högre procentsats på allt som köpts under perioden så fort en tröskel har passerats, inte bara på volymen som överstiger den. Den korrekta periodiseringen för den första månaden beror därför på om tröskeln till slut kommer att nås, vilket ekonomiavdelningen bara kan prognostisera. Korrigeringen kommer senare, och det är där de obehagliga överraskningarna finns.
Volym förvärrar båda problemen. En medelstor distributör kan ha flera hundra leverantörsavtal och dessutom erbjuda kundrabatter, var och en med sina egna produktgrupper och datum. Antalet kombinationer överstiger snabbt vad ett kalkylblad kan hantera utan att fel uppstår som ingen märker, vilket är det återkommande mönstret för datakaos inom B2B-distribution. Ingenting fallerar synligt, vilket är anledningen till att det fortgår i åratal.
Vad bristfällig rabatthantering kostar en distributör
Ingenting går sönder och ingen kund klagar. Förlusterna ackumuleras ungefär i denna ordning.
- Tröskelvärden som missas med liten marginal: ett konto hamnar precis under en nivå som ingen bevakade, trots att den extra volymen hade varit lätt att nå
- Krav som aldrig ställs: rabatter som tjänats in på mindre avtal förblir outnyttjade, eftersom det krävs mer arbete att räkna ut rättigheten än vad kravet är värt
- Underbetalningar som accepteras: en leverantörskredit är lägre än förväntat men accepteras, eftersom det kostar mer att kontrollera den än vad mellanskillnaden är värd
- Affärer prissatta med fel marginal: offerter baseras på en bruttomarginal som ignorerar rabatter, vilket gör att lönsamma affärer nekas medan olönsamma affärer vinns
Den fjärde punkten är den dyra, eftersom det inte rör sig om ett bokföringsfel. Företaget fattar kommersiella beslut baserat på en marginal som inte är den marginal affären faktiskt kommer att generera.
Varför avgör rabatter den verkliga marginalen snarare än bruttomarginalen?
Inom distribution utgör rabattintäkter ofta en betydande del av nettovinsten snarare än en avrundningspost. Bruttomarginalen på fakturan är därför ofullständig avsiktligt. Rabatten som förvandlar en olönsam affär till en bra affär anländer veckor eller månader efter att försäljningen bokförts. Ett marginaltal som exkluderar detta kan peka ut fel produkter, kunder och affärer.
Den praktiska konsekvensen drabbar säljteamet. En säljare som kan se att ett konto ligger precis under nästa nivå har möjlighet att ta ett specifikt samtal. Den som bara arbetar utifrån bruttomarginal vet inte att den möjligheten finns, vilket är en kommersiell förlust snarare än en bokföringsmässig. Att stänga gapet beror på var beräkningen körs och vilken data som når den.
Så här stöder en integrationsplattform hantering av rabatter
Distributörer hanterar rabatter på ett av tre sätt, och varje val har sina specifika svagheter. En dedikerad plattform för rabatthantering är bra på att modellera komplexa avtal, men är aldrig mer exakt än den transaktionsdata som hämtas från affärssystemet (ERP). Affärssystemets inbyggda rabattfunktion klarar standardstrukturer men har svårt med hårt förhandlade undantag. Kalkylark är vad de flesta distributörer faktiskt använder, vilket skapar ett beroende av en enskild person. Den manuella grunden är vad automatisering inom grossistledet oftast tas in för att ersätta.
Inget av de tre alternativen är där transaktionerna faktiskt registreras. Beräkningen sker alltid ett steg ifrån den data den är beroende av, och det är det avståndet som en integrationsplattform (iPaaS) är till för att överbrygga. På Alumio iPaaS sker arbetet i fyra former.
- Kvalificerande transaktioner levereras kontinuerligt: händelsestyrda datarutter skickar försäljnings- och inköpsposter till beräkningen i realtid, så att framsteg mot tröskelvärden är aktuella istället för att behöva sammanställas vid månadsskiftet
- Produkt- och kundgrupperingar omformas: en datatransformator mappar transaktioner mot de produkthierarkier som varje avtal använder, eftersom leverantörer sällan grupperar produkter på samma sätt som en distributör
- Periodiseringssiffror levereras till ekonomiavdelningen: beräknade positioner förs in i affärssystemet enligt en fastställd cykel, så att huvudboken får en beräknad siffra istället för en uppskattning
- Kreditnotor förs tillbaka för kontroll: leverantörernas kreditnotor når systemet som innehåller det ursprungliga anspråket, så att en diskrepans mellan begärt och betalt belopp synliggörs istället för att döljas
Dessa flöden konfigureras snarare än att byggas manuellt för varje avtal, med en kodtransformator tillgänglig där konfigurationen inte räcker till för att uttrycka en regel. Ett nytt leverantörsavtal blir en konfigurationsändring istället för ännu en flik i ett kalkylark. Det som förändras är inte beräkningens noggrannhet, utan när den är tillgänglig.
Vad rabatthantering ger när positionen är synlig
Rabatthantering behandlas vanligtvis som en ekonomisk skyldighet som beräknas korrekt vid periodens slut, snarare än något man agerar utifrån medan perioden fortfarande pågår.
Inom grossist- och distributionsledet är positionen uppdelad på tre avdelningar. Kommersiell direktör prissätter affärer och behöver veta vad en kundrabatt kommer att kosta. Försäljningschefen arbetar med konton mot tröskelvärden och behöver veta hur långt det är kvar till varje mål. Ekonomichefen ansvarar för periodiseringen och försvarar antagandena bakom den. Ingen av dem ser helhetsbilden.
Att göra positionen synlig medan det fortfarande finns tid att påverka den förändrar syftet med rabatthantering. En nivå inom räckhåll blir ett mål istället för en missad möjlighet, och en affär kan prissättas utifrån den marginal den faktiskt kommer att generera. När positionen beräknas kontinuerligt istället för att sammanställas vid periodens slut, upphör rabatter att vara den del av marginalen som distributören får reda på sist.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
