Tracking marble slabs: why quantity-based inventory cannot do it

Stone inventory cannot be counted, only listed. Every slab has its own dimensions, thickness, finish and vein pattern, and a customer buying one is buying that specific object rather than a quantity of a product. Inventory systems are built on the opposite assumption — that stock is a number against an item — and no amount of configuration reconciles the two.

This is the hardest catalogue problem in building materials, and it is worth understanding precisely before buying anything.

What makes stone different from every other material?

Five properties, and each one breaks a different assumption.

No two units are equivalent. Two slabs cut from the same block differ in vein pattern. A customer who saw one and received the other has received the wrong thing, even though the item code matches.

Dimensions vary per piece. Slabs are not produced to a standard size. Each has its own length and width, so area — the thing you actually sell — has to be held per slab.

Sequence matters. Slabs cut consecutively from a block can be book-matched or run continuously across a large surface. Once separated, that relationship is gone, so block and bundle grouping has to be preserved through the whole system.

Price varies within a product. Two slabs of the same material can be priced differently on appearance, grade and defects. A single rate against the item code is a starting point, not the price.

Reservation holds an object. When a customer holds a slab, you have not allocated one of forty — you have committed that one. Releasing it must return that specific slab to availability, not increment a counter.

What happens when you force it into a normal system?

Two workarounds, both of which fail on a predictable timescale.

One item per slab, quantity one. This works, briefly. Then the item master fills with thousands of records that will never repeat, search stops being useful, and reporting by material becomes impossible because every slab is its own product. Businesses reach this point within a year or two of adopting it.

One item per material, slab details in a spreadsheet. The system holds a quantity, and the real information — which slabs, what sizes, which are reserved — lives beside it. The spreadsheet becomes the truth, one person maintains it, and the ERP holds a number that nobody relies on.

The second is more common and more dangerous, because it looks like the business has a system.

What does slab-level inventory actually require?

Level	What it holds	Why it exists
Material	Name, origin, category, base rate	What the customer asks for
Block	Source block reference, quarry lot	Establishes which slabs relate to each other
Bundle	Slabs cut consecutively, kept in order	Book-matching and continuous runs
Slab	Unique ID, dimensions, thickness, finish, grade, photograph, status	The thing actually sold

Everything else follows from that structure. Availability is a status per slab, not a number. Area is calculated per slab and summed. Pricing applies at material level with adjustment at slab level. Reservation sets a status against an identified object.

None of this is exotic. It is simply a different shape from what packaged inventory software provides.

Why does photography decide whether it works?

Because customers select from images, and an incomplete image library is worse than none.

If half your slabs have photographs, customers learn that the catalogue cannot be trusted and go back to visiting the yard. The system has then added work without removing any.

Which makes capture speed the critical design decision. If photographing a slab and attaching it to the right record takes more than a few seconds at the yard, it stops happening during a busy week — and once there is a backlog, it never gets cleared.

Practical requirements: capture on a phone, works with poor connectivity, slab identified by scanning rather than typing, and no desktop step afterwards. Anything that requires someone to sit down later and match photographs to records will fail.

What does this change commercially?

You can sell without a yard visit. An architect in another city can select a specific slab and know they will receive it. That widens your market considerably.

Reservations stop being verbal. “Hold that one for me” becomes a status with a name and a date against it, rather than a note somebody may not have passed on.

You can see what is actually sitting. Slab-level ageing shows which material has not moved in a year — real money that a quantity-based system hides inside a total.

Disputes reduce. A photographed, identified slab against an order is difficult to argue about on delivery.

This is the kind of system we build under custom software and product engineering, because no packaged product models it properly.

Common questions

Does this apply to tiles as well?

Partly. Tiles need batch tracking, which is a lighter version of the same idea — stock that is not fully interchangeable. But tiles within a batch are equivalent, so quantity still works below batch level. Stone has no equivalent level.

How do you handle offcuts and remnants?

As slabs with their own dimensions and a status marking them as remnant. They are real, saleable stock and most businesses lose track of them entirely, which is a quiet and recurring loss.

Can this connect to our existing accounting system?

Yes, and that is usually the right architecture. Slab detail lives in the specialised system; the accounting system receives the invoice and the value. It does not need to know about individual slabs, and it will be happier not knowing.

What about businesses that also sell processed pieces?

Cut-to-size work adds a production step, where one slab becomes several pieces with their own dimensions and a wastage figure. The slab model extends to it, but the yield calculation is genuinely difficult and worth scoping carefully.

More on this: why generic ERP breaks and build, buy or neither. For how we work with this segment, see stone & marble.