Modern supply, modern demand, and a Bronze-Age transaction layer

Walk into any minimarket in Amman and the supply side looks modern: branded trucks, barcoded cases, a distributor's ERP somewhere in an office. The demand side looks modern too: a smartphone in the owner's pocket, a card terminal by the till. The layer between them does not.

Orders arrive as voice notes and photos on WhatsApp. Someone re-keys them that evening, and 8 to 15% of the lines arrive wrong. Prices are agreed by phone, so the same SKU from the same supplier can move by 18% depending on which rep took the call, with no trail. Invoices are paper. Returns are credited weeks later. A retailer ordering from eight suppliers has eight threads, eight invoices arriving at different times, and eight cheques to write.

None of the people involved are the problem. The supplier's ERP is fine at inventory and accounting. The retailer knows their shelves better than any dashboard. What is missing is a transaction layer: a place where the order, the price, the terms and the invoice exist once, structured, visible to both sides.

What a transaction layer has to do

It has to let a retailer build one cart across every supplier and split it automatically into a sub-order per supplier, each carrying that supplier's prices and credit terms. It has to show the final price, after every discount and tax, before the retailer confirms, and print the same number on the invoice. It has to enforce a credit limit at the moment of ordering rather than in a rep's memory. And it has to do all of this in Arabic first, because the person picking the order at seven in the morning reads Arabic.

What it must not do

It must not replace the ERP; that stays the record for inventory and accounting. It must not run deliveries; suppliers keep their trucks. And it must not touch the money; cheques, transfers and cash stay exactly where they are today.

That is the whole scope of Madana. Not an operating system, not a bank, not a fleet. The layer that was missing.