Twee manieren om naar voorraad te kijken

Onlangs hebben we wat tijd besteed aan het bestuderen van het voorraadontwerp van TallyPrime.

Tally is boekhoudsoftware met een lange geschiedenis, en de manier waarop het met voorraad omgaat weerspiegelt een heel typische werkgewoonte van traditionele kleine bedrijven.

Een veelgebruikte aanpak is Periodic Inventory (periodieke voorraadopname).

Wanneer het bedrijf goederen of grondstoffen inkoopt, boekt het Purchases; bij verkoop boekt het Sales. De voorraad hoeft niet bij elke boeking in realtime het Inventory Ledger in of uit te gaan.

Tegelijkertijd heeft Tally een apart Inventory Module dat Stock Items, hoeveelheden en waarderingen registreert. Op de rapportagedatum berekent het systeem de Stock-in-Hand op basis van de werkelijke telling en leidt het de kostprijs van de verkochte goederen af via een klassieke boekhoudformule:

COGS = Opening Stock + Purchases − Closing Stock

Dit ontwerp is echt praktisch.

Veel traditionele kleine bedrijven hoeven niet elke dag de exacte realtime waarde van hun voorraad te kennen. Ze zijn gewend om in- en verkopen gewoon te boeken, aan het einde van de maand, het kwartaal of het jaar te tellen, en pas dan de werkelijke kosten en winsten te bepalen.

Dat is de kracht van Periodic Inventory: eenvoudig, met lage eisen aan de dagelijkse operatie.

De andere aanpak is Perpetual Inventory (permanente voorraadregistratie).

Bij elke inkoop stijgt de Inventory; bij elke verkoop daalt de Inventory en wordt de COGS erkend.

Het systeem kan dus op elk moment antwoorden:

Hoeveel voorraad hebben we nu? Wat is die waard? Wat hebben de al verkochte goederen gekost? Wat is onze brutomarge in realtime?

Voor e-commerce, detailhandel, groothandel en gestandaardiseerde productie wordt deze aanpak steeds belangrijker. Bestellingen, inkoop en voorraad zijn al gedigitaliseerd, dus het systeem kan deze informatie prima realtime bijhouden.

Daarom is het ontwerp van SnapLedger niet om simpelweg Periodic of Perpetual te kiezen, maar om de basis verschillende Cost Flows te laten begrijpen.

Want echte kleine bedrijven passen niet allemaal in hetzelfde model.

Een e-commercebedrijf heeft misschien dit nodig:

Purchase → Inventory → Sale → COGS

Een heel klein handelsbedrijf voelt zich misschien meer op zijn gemak bij:

Purchases → Period-End Stock Count → Closing Inventory

En een meubelbedrijf dat op klantbestelling produceert, heeft misschien nauwelijks voorraad in de traditionele zin.

De klant plaatst eerst de bestelling; daarna koopt het bedrijf hout en beslag, investeert het arbeid en uitbested werk, en levert het zodra het stuk klaar is.

Voor zo'n bedrijf is het natuurlijkere pad eigenlijk:

Customer Order → Project → Materials & Labour → WIP → Delivery → COGS

Het belangrijkste vermogen is hier misschien niet de traditionele Stock-in-Hand, maar Work in Progress (WIP, werk in uitvoering).

Dus in SnapLedger willen we niet dat de software vooraf bepaalt hoe een bedrijf zijn voorraad zou moeten beheren.

De basis kan Perpetual Inventory en Periodic Inventory ondersteunen, maar ook Project Costing en WIP.

En wat Snappy echt zou moeten begrijpen, is:

Hoe run je je bedrijf eigenlijk?

Leg je eerst voorraad aan en wacht je tot klanten kopen?

Of koop je pas in nadat een klant een bestelling heeft geplaatst?

Moet je op elk moment het voorraadniveau van elke SKU kennen?

Of vind je het belangrijker hoeveel kosten elk klantproject al heeft opgenomen, en hoeveel het naar verwachting zal verdienen?

Traditionele boekhoudsoftware begint vaak met "How should inventory be recorded?"

Wij beginnen liever met een andere vraag:

"How does your business actually work?"

En laten dan de boekhoudkundige verwerking zich aanpassen aan het echte bedrijfsproces.

SnapLedger, your life easier.