A dealer portal when your accounting system does not know your stock

A manufacturer wants a dealer portal: a place where its resellers log in, see their own prices and order online instead of emailing a sales rep. The accounting system holds every dealer’s discount structure, so the pricing is solved. Then the first real question comes up: what does the portal show for stock? And the answer is that the accounting system does not track quantities at all. Stock lives in a spreadsheet. This is more common than anyone building portals would like, and it does not stop the project. It changes its shape.

What the portal needs from the business system

A dealer portal is only as good as three things it gets from upstream: who the dealer is and what they may see, what they pay, and what they can have. Most small-business accounting packages handle the first two well. Customer records, price lists, discount percentages by customer or by product group, and often a credit limit are all there and can be read through the package’s API or a scheduled export.

The third one is where it gets interesting. Many accounting systems are not inventory systems. They record what was sold and invoiced, not what is on the shelf. The business knows its stock, but the knowledge is in a sheet someone updates, or in the head of the warehouse manager.

Three ways to handle it

• The portal does not show stock. Every order is an order, confirmed by a person with a lead time. This is honest and simple, and for made-to-order or long-lead products it is the right answer. Dealers already work this way by email.
• The spreadsheet becomes the feed. If stock is maintained in a sheet, the portal can read the sheet on a schedule and show availability as a status rather than a number: available, low, on order. The sheet gains a few rules, such as one row per product code, and the person who maintains it keeps doing exactly what they do now.
• The portal becomes the stock record. Quantities are captured in the portal when goods arrive and decremented when orders are confirmed. This works, and it is the start of the business having an inventory system, but it moves a job into a new place and someone has to own it from day one.

We have shipped all three. The second is the usual answer for a first version, because it changes nothing about how the business works and gives dealers more than they have today.

Credit and pricing need the same honesty

The same conversation applies to credit. The accounting system may hold a credit limit and an outstanding balance, but if payments are captured late or allocated loosely, the number is not reliable enough to block an order on. Early on, the portal shows credit status as information for the sales desk and does not enforce it. Enforcement comes later, once the data is trusted, and that is a business decision rather than a technical one.

Pricing, by contrast, is usually solid, because invoicing depends on it. Dealer-specific discounts, list prices and retail prices come straight from the system and the portal never holds a price of its own. When the accounting system changes a discount, the portal reflects it on the next sync, and nobody maintains two price lists.

What this means for the build

The portal is a storefront with customer accounts, group pricing and an order flow that ends in the accounting system, not in a payment gateway. Orders land as sales orders or quotes for the office to confirm, which keeps the existing process intact and gets the first version live in weeks. Stock and credit are integrated as far as the source data deserves, and the integration deepens as the business’s own systems catch up.

The mistake is to delay the portal until the business has a perfect inventory system. The portal is usually the reason it gets one.

We build dealer and B2B portals against whatever system the business runs, from full ERPs to accounting packages with a spreadsheet beside them.