eCommerce ERP Consultant, Saudi Arabia

One order, one e-invoice: deciding who issues it

Under ZATCA e-invoicing, sales to consumers generally require a simplified tax invoice produced by a compliant solution, and many taxpayers must integrate their invoicing with the authority. For an online business the practical question is which system issues that invoice. The store platform may generate one at checkout. A marketplace may issue documents on your behalf or expect you to. The ERP may also be configured to invoice every order it receives.

If two systems issue invoices for the same sale, you have duplicates in your tax data. If neither does for a chat order taken by phone, you have a gap. I build an invoice ownership matrix: for each channel, the system that issues the invoice, the system that holds the record, how credit notes for returns are raised and how the data reaches the ledger.

The matrix then drives configuration and testing:

• Store orders: either the store platform issues and the ERP imports, or the ERP issues and sends the reference back to the store.
• Marketplace orders: confirm the marketplace's role with your advisor and the marketplace itself.
• Social and phone orders: entered as sales orders in the hub, invoiced by the ERP.
• Returns: a credit note linked to the original invoice, never a negative sale.

Compliance status depends on the vendor, edition and setup, so confirm it with each vendor and your tax advisor. My Saudi ERP consultant page covers FATOORAH for the wider business.

mada, wallets, pay-later and courier cash in one reconciliation

A Saudi online store can receive money through six or seven routes in a single day. mada and credit cards settle through a payment gateway. Apple Pay and other wallets often settle through the same gateway. Pay-later providers pay the merchant and collect instalments from the shopper. Marketplaces pay after their deductions. Couriers collect cash on delivery and remit later. Each route has its own fees, its own timing and its own file format.

The design principle is a clearing account per route. Orders post the gross sale and VAT. Settlement files post fees, refunds and holds. Bank receipts clear the balance. For courier cash, the clearing account works as a receivable from each courier, aged by shipment, so slow remitters are visible.

Refunds need a route for each payment method: back through the gateway for cards and wallets, through the provider for pay-later orders, and by bank transfer or store credit for cash orders. I define who approves each route and how it posts.

Once this runs from settlement files rather than spreadsheets, the finance team can compare the real cost of each payment method, including refused cash parcels. That comparison often shapes checkout design, such as how prominently prepaid options are offered. The ERP integration work covers how each file is imported and validated.

Returns, consumer rules and customer data

Saudi Arabia has an e-commerce law and related consumer protection rules that set expectations for online sellers, including what must be disclosed before purchase and how cancellations and returns are handled. The Personal Data Protection Law adds obligations on how customer information is collected and used. Which of these apply to you is for your lawyer to confirm; the ERP and store design have to make those obligations workable.

For returns, I set out a recorded sequence: request with a reason code, collection by courier, inspection and condition grade, decision to restock or write off, refund through the correct route and a credit note linked to the original e-invoice. Each step has an owner and a target time, and a report shows open returns by age so customer service can act before a complaint arrives.

For customer data, the design limits who sees phone numbers and addresses, stores each shopper's marketing permissions inside their profile, and stops order lists being exported to spreadsheets that circulate by chat. Courier and marketplace integrations should exchange only the fields needed for delivery.

Returns data then feeds buying and marketing. When reason codes are reliable, the business can see whether a product comes back for sizing, damage in transit or a description that does not match, and fix the cause rather than absorbing the cost.

Margin by region after delivery, returns and ad spend

Delivering across the Kingdom is not one cost. A parcel within Riyadh, Jeddah or the Eastern Province cities costs less and arrives faster than one to a smaller town far from the courier's hubs, and refusal rates on cash orders can differ by area. If margin is reported as a national average, unprofitable regions and products hide behind profitable ones.

I define margin per order with region as a core dimension:

1. Sale value after discounts, coupons and refunds.
2. Minus landed product cost, with freight, customs duty and clearance charges for imported goods.
3. Minus delivery cost for the actual route, plus allocated cost of failed attempts and return trips.
4. Minus gateway, pay-later, marketplace and courier collection fees.
5. Minus allocated advertising from Snapchat, TikTok, Google, Meta and marketplace campaigns.

Ad spend arrives by campaign and day, so the allocation rule must be agreed between finance and marketing. With that in place, my paid marketing work can target regions and products that earn after delivery, and shift budget away from those that only look good on clicks.

Stock placement follows the same logic. If one region drives volume, a second fulfillment point may cut delivery cost, and the warehouse side of that decision is discussed on my Saudi Odoo Inventory consulting page.

Choosing a platform and switching without losing orders

A common Saudi setup is a store on a local platform, marketplace seller portals, courier dashboards, a gateway portal and an accounting system fed by summaries. The next step might be a stronger accounting and inventory core with connectors, or a full ERP with its own order hub. I score options on e-invoicing approach, Arabic-first documents, connector availability for your store platform and couriers, settlement imports, multi-warehouse stock and reporting.

Local store platforms and couriers change their interfaces, and not every ERP has a maintained connector for them. I check what exists today, who maintains it and what happens when it breaks, before it becomes a dependency.

Migration covers product masters with Arabic names and descriptions, unfulfilled orders, cash still held by couriers, gateway and marketplace money not yet paid out, store credit and gift card liabilities, plus a fresh stock count just before switchover. I keep go-live away from Ramadan, Eid, National Day sales and the large year-end sale events.

Live sessions are remote and fit the Saudi working week and clock; warehouse staff get recorded walkthroughs to watch between shifts. The Saudi Arabia hub and the eCommerce industry page add more context.