SERPA | ODOO ERP: B2B E-COMMERCE FOR DISTRIBUTORS

A procurement manager has placed an order, but the price on the portal does not match the negotiated contract. Finance has put the account on hold, yet the sales representative has promised delivery. By the time someone checks stock, the order has already been captured twice.

That is the operational problem behind B2B ecommerce South Africa projects. Distributors need a customer portal that reflects the same prices, credit position, stock and tax treatment that their teams use internally. For organisations operating across more than one entity or market, the portal must also preserve an auditable record of each approval and transaction.

At Serpa, we implement Odoo ERP for distributors that need a unified route from customer self-service to fulfilment, invoicing and collections. The portal is not a separate website with a stock feed. It is a controlled extension of the ERP.

Why a distributor portal needs ERP control

A B2B buyer does not behave like a retail shopper. They may order against a negotiated price list, require a purchase order number, have several delivery sites and buy through people with different authority levels. A branch manager may place orders, while a finance contact receives statements and an account director approves credit changes.

A standalone storefront can show products. It becomes unreliable when it must decide whether a particular customer can buy a particular item at a particular price on a particular credit status.

An ERP-integrated portal should use the master data already governed in the ERP:

| Portal requirement | ERP control behind it | Why it matters | | Customer-specific catalogue | Product records, contracts and price lists | A buyer sees the commercial terms assigned to their account rather than a public list price. | | Available credit | Credit limit, ageing and open orders | The system can apply the credit policy before an order moves into fulfilment. | | Order status | Sales, warehouse and delivery records | Customer service and the buyer work from the same status history. | | Invoice history | Posted invoices, payments and tax configuration | The customer can retrieve records without staff sending documents manually. | | Multi-user accounts | Contact roles and account permissions | A customer can separate buyers, approvers and finance users. |   This is where Odoo ERP and customer portal implementation need careful design. The most common mistake we see in portal planning is treating every contact under a customer account as though they should see the same prices, credit balance and documents. They should not.

Give each contact the minimum access needed for their role. A buyer may create an order. A finance user may download invoices. A director may approve a credit-limit request. That approach limits exposure of commercial and personal information, while making the approval trail more useful at month-end.

Price lists that match the commercial agreement

Price lists often fail because the business has built them around product categories, while sales agreements have been negotiated around customers, volumes, territories or a specific contract period. A portal can only display a reliable price when those rules have been formalised in the ERP.

For a distributor, we recommend defining who may create, change and approve a customer price list before the portal goes live. The system should retain the old price, new price, approver, effective date and affected customer account. That is the evidence a finance team needs when a customer disputes an invoice.

Worked example: a contract price that reaches the wrong buyer

Take an illustrative Johannesburg electrical wholesaler with twelve sales users and several contractor accounts. One contractor is offered a lower cable price for a defined project, but the discount is added to a broad customer category instead of the individual account. Other customers see the discounted price when they sign into the portal, and the finance team must correct invoices at the standard 15 percent VAT treatment for taxable local supplies.

The operational cost is not only the credit note. The team also loses the original audit trail because the approval happened in a spreadsheet rather than against the price-list rule. We would configure a customer-specific price list, an effective period and approval rights in Odoo ERP before publishing that price. The lesson is simple: if a discount belongs to one contract, do not put it on a general price list.

For customer portals, the useful question is not, “Can the site show different prices?” Most B2B ecommerce platforms for African businesses can do that at some level. The question is whether the price shown, order accepted and invoice posted all come from the same governed rule.

Credit limits are a workflow, not a warning message

A portal that shows “credit available” without a defined order-hold process creates risk. The system must state what happens when the order would exceed the limit, when invoices are overdue or when a customer has a disputed balance.

A practical credit workflow has four decisions:

1.       Set the limit and terms: Record the approved credit limit, payment terms and authorised approver against the customer account. This gives sales and finance one reference point.

2.       Calculate exposure: Include posted receivables and open sales orders according to the business policy. An order not yet invoiced can still consume risk capacity.

3.       Apply the hold: Stop automatic confirmation or release to the warehouse when the limit is exceeded. A visible internal exception is better than an informal phone call.

4.       Record the override: Require a named approver and reason when an order proceeds outside policy. This makes the decision auditable later.

The National Credit Act point needs particular care in South Africa. Offering customer credit is not automatically outside the Act merely because the sale is B2B. The National Credit Regulator maintains a public register of credit providers, and a distributor should obtain legal advice on whether its account-credit arrangement and customer type trigger registration or affordability requirements.

Do not ask your portal implementation partner to make that legal determination. Ask them to configure the approved policy after your legal and credit teams have decided it.

Worked example: the customer who can still order after a hold

Consider an illustrative Cape Town industrial supplies distributor whose monthly taxable sales are approaching the R2.3 million compulsory VAT-registration threshold. A buyer has overdue invoices, but a sales representative creates a portal order under a different contact on the same parent account. The warehouse sees a confirmed order, while finance sees the credit hold only after dispatch planning has started.

The immediate cost is a preventable fulfilment exception and a difficult collection conversation. We would link all authorised portal contacts to the same commercial account, calculate exposure at account level and route an exceeded-limit order to a credit approver. If the group structure genuinely requires separate limits, model those entities separately rather than relying on contact names.

South African VAT, POPIA and portal obligations

The portal must be part of your compliance design, not a customer-facing layer that compliance discovers after launch. As of September 2026, several South African rules should influence the configuration and operating process.

VAT registration and tax invoices

From 1 April 2026, a business whose taxable supplies exceed, or are likely to exceed, R2.3 million in any consecutive 12 months must register for VAT within 21 business days. Voluntary registration may be available from R120,000, subject to conditions. SARS registration is handled through SARS eFiling or eBooking.

The old R1 million compulsory-registration threshold is no longer the correct planning figure. Finance should monitor taxable supplies from the ERP, because waiting until an annual review can leave too little time to act.

Once registered, configure compliant tax invoices and apply the standard 15 percent VAT rate to taxable local supplies unless a zero-rating or exemption applies. A portal should not let commercial users override tax treatment simply to match a customer’s requested total. Tax configuration belongs in the ERP, with documented exceptions and approvals.

POPIA applies to business contacts and company data

Customer, director and contact information, including information relating to juristic persons, is personal information under POPIA. This is why the common assumption that “B2B data is outside POPIA” creates exposure.

A portal operator processing personal information must register its Information Officer with the Information Regulator through the eservice’s portal. The officer must ensure a compliance framework, PAIA manual, access-request process and privacy impact assessment. POPIA has applied since 1 July 2021.

Since 1 April 2025, security-compromise notices must be submitted through the Information Regulator eServices portal. In August 2025, the regulator clarified that POPIA has no low-risk breach-reporting threshold. If information is compromised, notify the Information Regulator and affected people as soon as reasonably possible.

Your ERP provider, marketplace provider or hosting supplier may have contractual security responsibilities. The distributor still needs reasonable technical and organisational safeguards and a tested incident process. Treating the supplier as solely responsible for a breach is a recurring governance mistake.

Consumer and electronic transaction boundaries

The Consumer Protection Act does not apply to a transaction where the customer is a juristic person with asset value or annual turnover of at least R2 million. That is not a blanket exclusion for all business buyers. Your legal team should assess the customer type and transaction before portal terms make broad statements about consumer rights.

Where a portal sells to consumers, the Electronic Communications and Transactions Act supports electronic transactions and makes website disclosures relevant. Keep terms, contact details, ordering steps, prices and transaction records accessible. This matters even where the main portal strategy is B2B, because an organisation may serve mixed customer types.

Designing for multi-entity distribution across Africa

Distributors across East and Central Africa often need shared product governance and group visibility, while each legal entity retains its own customers, tax treatment, bank processes and approval policy. That is a multi-entity ERP design issue before it is an e-commerce design issue.

Do not begin with the portal theme or catalogue layout. Begin with the commercial model:

| Design decision | Question for the board and operating team | Implementation consequence | | Legal entities | Which company contracts, invoices and collects from each customer? | Controls which entity owns the customer account and tax document. | | Customer hierarchy | Is credit assessed by branch, company or group? | Determines how exposure is calculated and who can order. | | Inventory promise | Is stock allocated from one warehouse or several? | Determines whether availability can be presented in real-time. | | Price governance | Who can approve an exception, and for how long? | Determines approval workflow and audit records. | | Data ownership | Which role can view directors, contacts and payment history? | Determines portal permissions and POPIA controls. |   For a smaller distributor, do not build a marketplace-style portal with extensive custom workflows before the core sales, inventory, invoicing and credit processes are stable. An ERP integrated portal for SMEs should start with account access, approved price lists, order placement, order tracking and document retrieval. Add more only when the operating team can own the process.

For a larger group, we normally scope integration architecture early. ERP marketplace integration can be justified when marketplaces, supplier feeds or external customer systems must exchange orders and availability. It needs clear ownership for failed messages, duplicated orders and product-data changes. Integration without exception management merely moves manual work into a queue nobody watches.

What to require from a B2B ecommerce implementation

The best B2B ecommerce sites Africa teams admire are usually not the ones with the most visual features. They are the ones that consistently show the customer the right commercial position and give finance an auditable record.

Before approving a build, require these outputs:

●        A customer-account and contact-permission matrix, reviewed by sales, finance and the Information Officer.

●        A documented price-list approval process with effective dates and exception controls.

●        A credit-control workflow showing order holds, overrides and release authority.

●        VAT configuration and invoice testing for the entity that will sell through the portal.

●        A POPIA privacy impact assessment and security-compromise response process.

●        Integration test cases for duplicated orders, failed status updates and customer changes.

●        A month-end reconciliation between portal orders, ERP sales orders, invoices and payments.

These are implementation deliverables, not optional governance paperwork. They determine whether the portal produces visibility or creates a second, less controlled version of the truth.

Frequently Asked Questions

Can an Odoo ERP portal show different prices to different customers?

Yes, where customer-specific price lists and access rules have been configured in the ERP. The important control is that the portal price, sales order and invoice use the same approved rule, with changes retained in an audit trail.

Does POPIA apply to a B2B customer portal?

Yes. Under POPIA, customer, director and contact data, including data on juristic persons, is personal information. The operator needs an Information Officer, a compliance framework, a PAIA manual, an access-request process and a privacy impact assessment.

What is the South African VAT registration threshold for a distributor?

As of September 2026, compulsory VAT registration applies when taxable supplies exceed or are likely to exceed R2.3 million in any consecutive 12 months. Registration must occur within 21 business days. Voluntary registration may be available from R120,000, subject to conditions.

Are B2B credit accounts excluded from the National Credit Act?

No. B2B credit does not automatically fall outside the National Credit Act. Obtain legal advice on the account-credit arrangement and customer type, then configure the approved credit workflow in the ERP.

A customer portal should reduce order handling without weakening price governance, credit control or compliance. Request a Consultation with Serpa to assess your Odoo ERP, customer portal and multi-entity distribution requirements.