A wholesale distributor ordering portal, scoped around the reorder

The brief arrives as a B2B web shop. A distributor has two hundred retail customers, orders come in by phone, WhatsApp and a rep's notebook, and somebody has decided the answer is an online store. The reference everyone has in mind is a consumer checkout, and that reference is wrong in almost every detail that matters here.

A retailer buying from you is not shopping. They know what they sell, they know what ran out, and they want to place a near-identical order in under two minutes without talking to anyone. Design for that and adoption is fast. Design a catalogue with categories and a search bar and you will build something your customers politely ignore while continuing to message the rep.

The reorder is the product

Open the portal on the customer's own order history, not on a product grid. The first screen should be their last order with quantities already filled in, and a single control that says order this again. Everything else in the product exists to handle the exceptions to that screen.

This is not a shortcut, it is the actual shape of the demand. Wholesale buying is high frequency and low variety per customer. A hardware shop orders the same fasteners every month and adds one new line a quarter. If your portal makes the common case one tap and the rare case three screens, you have matched the work. The usual mistake inverts that.

The price list problem that sinks these builds

Here is the requirement that is almost never in the first brief and almost always in the second. Every retailer has their own price, and sometimes their own price per product, negotiated by a rep years ago and recorded in nobody's system.

A consumer store has one price per item. A distributor has a price matrix: customer tier, volume break, promotional period, and a handful of individually negotiated exceptions that exist only in the commercial manager's head. Showing a retailer the wrong price is not a cosmetic bug. It is either a sale at a loss or an angry phone call about why the portal quotes higher than the rep, and two of those will stop adoption dead.

So before any code, the pricing rules have to be written down and made decidable. Who is in which tier, what the volume breaks are, what beats what when two rules apply, and where the exceptions live. That exercise usually takes longer than building the ordering screen, and it is the real reason these projects run late. It is also work only the distributor can do, which is uncomfortable but true.

What the tax authority forces into scope

An ordering portal in this region is not just a basket. It sits upstream of a tax document, and the rules about that document are published, dated and not optional.

In Saudi Arabia, ZATCA's e-invoicing requirements landed in two phases, generation from 4 December 2021 and integration from 1 January 2023, with the integration phase rolled out in numbered waves since. ZATCA's current notice sets Wave 25 at taxpayers whose VAT-subject revenues exceeded SAR 187,500 in 2022, 2023, 2024 or 2025, requiring integration with the Fatoora platform by 1 February 2027. That threshold reaches a lot of ordinary distributors. ZATCA also states that taxpayers may use any compliant solution provider, which matters because it means the portal does not have to do the invoicing itself.

In Egypt the same shape applies through the Egyptian Tax Authority. Its e-invoicing SDK documentation describes a system taxpayers use to register their issued documents with the Tax Authority, through APIs exposed to taxpayer ERP and POS systems. Note the wording: ERP and POS systems. Your ordering portal is neither, which is the point of the next paragraph.

The design conclusion is the useful bit. Do not make the portal a tax document issuer. Let it create an order, hand that order to whatever already produces the compliant invoice, and show the resulting document back to the customer. Build it the other way round and every future change in the rules becomes a change in your web application, which is the most expensive place to absorb a regulatory amendment.

Phase one, and what can wait

The row that surprises people is online payment. In consumer ecommerce the payment is the product. In wholesale, the customer has thirty or sixty day terms and a credit limit, so a card form at the end of the flow is answering a question nobody asked. Add it when a segment of your customers actually wants to prepay, not because a checkout is supposed to have one.

Where the integration cost sits

Not in the portal. The portal is a few screens. The cost is in the three questions it has to answer truthfully: what does this customer pay, what do we have in stock, and where is their order. All three answers live in somebody else's system, usually an ERP that was configured years ago by someone who has left.

Price that honestly at the start. The ranges and what moves them are in what an integration between two systems really costs. The stock half is the one that bites hardest, because showing availability means deciding what available means when the warehouse count and the system count disagree, which is the whole subject of an inventory system scoped to stock truth. The invoice half has its own traps around credit notes and part payments, covered in automating invoice generation and the three places it breaks.

The access control shape is the same as any portal where one customer must never see another's records, and the phase-one discipline that works there works here too. We wrote that up in a client portal for a professional services firm, scoped honestly.

The honest case for not building it

If your orders come from fewer than about thirty regular customers, a portal is probably the wrong spend. The reps know those accounts, the ordering overhead is small, and the money is better spent on making stock data correct so that nobody promises what is not there. A portal over wrong stock data just publishes the wrongness to your customers, faster.

There is also a commercial question that sits before the software one. If the problem is that you do not have enough retailers rather than that ordering is slow, a portal solves nothing. Our colleagues at BDG Labs set out how that side actually works, including the checks worth doing before you sign anyone, in finding a distributor in Saudi Arabia, rules and checks. Work out which problem you have before commissioning either.

The case for building is specific. You have enough customers that reorder volume is a real operational load, your pricing rules can be written down, and your stock data is good enough to show a customer. Where that leaves you on build versus buy is the decision order in custom software versus off the shelf. Plenty of distributors should take a product and accept its pricing model rather than build their own, and the pricing matrix is usually the thing that decides it.

One last thing to insist on, whichever route you take. Before launch, have the commercial manager place a real order as three different customers and check the prices against what those customers were last invoiced. Not a test order with test data. Three real accounts, three real price lists. If the numbers match, you have a portal. If they do not, you have a support queue with a login page.