ERP Workflow Design for SMEs — What Big-ERP Gets Wrong

Walk into any small or medium-sized business in retail, pharmacy, distribution, or trading and ask what they use for "ERP." You'll get one of three answers:

1. "We use Excel."
2. "We bought [big-ERP] last year, and only the accountant uses it."
3. "We have a custom system the previous developer built, and we're afraid to touch it."

This is not because SMEs are technologically backward. It's because the ERP industry sells systems designed for businesses ten times larger than its actual buyer, and the buyer correctly recognises that 80% of what they're paying for doesn't apply.

I've designed ERP workflows specifically for small and medium retail businesses — clothing, pharmacy, POS, shoes — and the pattern that works looks fundamentally different from what SAP or Odoo will sell you. This is what those workflows actually need to do, what they can leave out, and how to design them so a four-person shop can actually use them.

What an SME actually does

A typical 5-20 person retail business runs these processes every day:

• Buys stock from a supplier — sometimes once a week, sometimes whenever they're running low.
• Receives stock — counts boxes, marks discrepancies, tags items.
• Sells stock — at the counter, or to walk-ins, or on credit to repeat customers.
• Handles payments — cash, card, mobile wallet, "I'll pay you next month."
• Manages returns — customer didn't like it, sometimes a refund, sometimes credit.
• Tracks the books — who owes us, who we owe, how much is in the till, and what's the margin.
• Reports to the boss — typically informally, at the end of the day, by phone or WhatsApp.

That's it. There are nuances per vertical (pharmacy has prescription tracking, clothing has size/colour variants, services have time billing), but the spine is identical.

A big ERP tries to model 200 processes. An SME-ERP should model exactly these 7, deeply.

The first design decision: simplicity over completeness

Every "feature" you add to an SME-ERP increases the chance that the owner stops using it. The system has to work for someone who is also running the till, calling suppliers, and managing two part-time staff. They have minutes per day to give to the software.

A useful test: can the owner walk a new employee through the whole system in 30 minutes? If not, you've added too much.

Specifically, you can omit nearly all of:

• Multi-currency (one currency).
• Multi-warehouse (one shop, maybe two branches — but not "warehouses").
• Approval workflows beyond a single tier.
• Demand forecasting, MRP, MPS, BOM explosions.
• Activity-based costing.
• "Configurable" means anything that isn't really configurable for this business.
• A web app that takes 10 seconds to load.

What you cannot omit:

• Stock that updates the moment a sale or purchase is recorded.
• A receipt that prints from the same screen on which the sale was entered.
• A way to take a credit sale and remember that the customer owes money.
• A daily summary that the owner can read on their phone in under a minute.

Core workflows, designed for small

1. Sale at the counter

The single most-used screen. It has to be fast — faster than a phone calculator.

┌────────────────────────────────────────────┐
│ POS                                  Today │
├────────────────────────────────────────────┤
│ Search/scan: [_______________]    │ Total: │
│                                   │ 1,250  │
│ Items in cart:                    │        │
│ - Shampoo 200ml      x2  →  240   │ Cash   │
│ - Soap                x1  →   80   │ Card   │
│ - [Add row…]                       │ Credit │
│                                   │        │
│ Customer (optional): [__________]  │ Print  │
│                                   │ Save   │
└────────────────────────────────────────────┘

Three things matter:

• One keypress per item. Scan the barcode or type two characters of the name + Enter.
• Default payment. 90% of sales are cash. "Cash" should be the default; "Credit" should require selecting a customer.
• No modal popups. Modals slow the till. Adjustments happen in line.

Behind the scenes, recording a sale writes to three tables: sales, sale_items, inventory_movements. Stock decrements atomically. The receipt prints. Total time from "customer hands over money" to "next customer can start" is under five seconds.

2. Purchase from the supplier

Less frequent but higher-stakes per transaction.

A purchase has a header (supplier, date, invoice number, due date) and a list of items (product, quantity, unit cost, total). On save, stock increments and a payable is created.

The form should let you:

• Pick a supplier from a recent-first list.
• Add items with the same speed as the sale screen.
• Enter unit cost with sane rounding.
• Mark payment terms (cash on delivery, 30 days, etc.) so the system schedules the payable.

The pattern that works for non-technical users: every purchase is a single screen, no multi-step wizards, no draft/confirm flow. Hit save and it's done. Mistakes are corrected by editing the same record with a full audit trail, not by navigating a refund process.

3. Stock received

Sometimes the purchase order and the actual receipt don't match. You ordered 10 boxes, you got 8. The system needs to handle this without making the user feel like an accountant.

The simplest pattern: a "Receive Stock" page that lists open purchase orders. Click one, edit the received quantities, save. The system records the discrepancy automatically — purchase_items.ordered_qty vs purchase_items.received_qty — and any difference is visible on the supplier page as a pending issue.

You don't need workflow approval. You need clear visibility.

4. Returns and refunds

Customer returns work in two flavours: with the receipt, and without. Both are common. The system should support both without making the staff feel like they're committing fraud to enter the second.

A return creates a negative inventory movement, optionally with a refund (cash out or credit-to-customer-account). The audit trail must clearly identify the original sale if it exists, and the staff member who processed the return.

For SMEs, the most important thing is speed — returns happen at the till, with a customer waiting. The screen should be exactly as fast as a sale, not a "returns and exchanges" wizard.

5. Accounts receivable (who owes us)

Credit sales accumulate as receivables. The system tracks:

• Total outstanding per customer.
• Days outstanding per receivable.
• Payment history.

A single screen, sortable by amount or by age. The owner glances at it, calls the customer who's been at 60+ days, takes a payment, and closes the receivable. That's the whole workflow.

Do not build customer statements unless a customer asks for one — and when they do, generate a PDF on the fly from the existing receivable data. Don't pre-build a "statement generator" module.

6. Accounts payable (who we owe)

Mirror of the above. Outstanding to suppliers, sortable, with payment recording. When the owner pays a supplier, they enter the payment, the payable closes (or partials, if it's a partial payment), and the cash position updates.

7. End-of-day summary

This is the workflow nobody designs for, and the owner uses most. Every evening, the owner wants to know:

• Total sales today (cash, card, credit broken out).
• Total expenses today.
• Cash in till.
• Closing stock value (rough).
• Receivables aged > 30 days.
• Payables due in the next 7 days.

One screen. One scroll. Optionally, a daily email or WhatsApp message with the same numbers. The owner reads it on their phone over dinner. That's the report module.

Do not build "interactive dashboards with drill-down" until the end-of-day summary works. The summary is what the owner needs. The dashboard is what consultants demo.

Vertical-specific extensions

Each retail vertical needs a few extra concepts. Important: extensions, not foundations. The same core engine, plus a small set of vertical-specific tables and screens.

Pharmacy — prescription tracking, expiry dates per batch, narcotic register, refrigeration alerts. The big one is expiry: every stock movement is tied to a batch with an expiry date, and the system warns when stock is approaching expiry. Without this, pharmacies sell expired medicine. With this, they don't.

Clothing — size/colour matrix per SKU. A "white shirt size M" is a distinct stockable unit from "white shirt size L." The product table has a parent product and variants. The till search is by product name, and the till resolution is by variant. Variants have their own barcodes.

Shoes — similar to clothing but with pair management and size-specific stock. Returns are higher because fit varies.

POS (general) — barcode scanning, scale integration (for produce), receipt printer driver, cash drawer trigger, end-of-shift cash reconciliation.

For each vertical, the core 7 workflows above are unchanged. You add one or two tables, one or two screens, and rules per vertical. Done right, a single multi-tenant platform can support all four with a feature-flag toggle per tenant.

The multi-tenant decision

If you're building this as a SaaS product to sell to multiple SMEs, the tenancy model is the second most important decision after the workflow design.

The pattern that works: subdomain-per-tenant (acmepharmacy.yoursaas.com), shared MySQL database with tenant_id in every row, feature flags per tenant. A TenantResolver filter at the framework level resolves the subdomain to a tenant ID once per request, and the rest of the application code can assume the tenant context.

Why not one database per tenant? Two reasons:

1. Operational overhead. 50 tenants is 50 databases to migrate, back up, and monitor. The cost of any schema change multiplies by tenants. With shared DB + tenant_id, one migration covers all tenants.
2. Cross-tenant analytics. You will want to know "average sales per tenant" or "how many tenants use the credit-sale feature." Trivial on shared DB. Painful across 50 separate databases.

The risk on shared DB is leakage — a query that forgets WHERE tenant_id = ?. Mitigations: a base model class that auto-applies tenant_id filtering, code review discipline, and integration tests that explicitly check tenant isolation.

The big-ERP "fully isolated databases" pattern exists because their enterprise customers demand it for compliance reasons. SMEs do not have those compliance reasons.

What I'd never build into an SME-ERP

A short list of features that big-ERP includes and that I've never seen a small business actually use:

• Multi-currency conversion with FX rate tracking.
• Multi-language UI (one language per tenant).
• Approval workflows with more than one tier.
• Demand forecasting (just look at last month).
• Activity-based costing.
• "Open balance" beginning periods (the system starts when it starts).
• Integration with external accounting systems that the tenant doesn't already use.
• Generic "custom fields" (90% of custom fields are never populated).
• A mobile app is distinct from the responsive web UI.

Every one of these is a project to build, a project to maintain, and a project that increases the surface area new staff have to learn. The cost is real. The benefit is usually zero.

Workflows that AI helps with — and ones it shouldn't touch

A small set of AI signals genuinely improves SME-ERP usability:

• Inventory reorder suggestions. Time-series analysis of sales velocity → suggest reorder before stockout. Owner approves with one click.
• Customer segmentation. Cluster customers by purchase pattern, surface top customers and at-risk customers.
• End-of-day anomaly detection. "Cash drawer differential is unusually high today." Owner investigates.
• Receipt parsing for purchases. Photograph supplier invoice, AI extracts line items, owner verifies. Saves manual entry.

Things AI should not touch in an SME-ERP:

• Automatic price changes.
• Automatic refunds.
• Automatic supplier orders without approval.
• Automatic deletion of anything.

The pattern is: AI suggests, human acts. Always. SMEs cannot absorb the consequences of an AI mistake at scale — there is no "compliance team" to clean up after the bot.

What success looks like

An SME-ERP is succeeding when:

• The owner uses the system daily (not just the accountant).
• A new staff member is productive in 30 minutes of training.
• End-of-day summary takes under 30 seconds to read.
• Reverse-engineering "what happened to this transaction" is one click on the audit log, not three.
• The owner can answer "how is the business doing" on their phone in under a minute.

If any of those fail, the system is too complex, regardless of how feature-complete it is.

Wrap-up

Big-ERP is designed for big businesses. The mistake is assuming you can shrink it to fit a small one by hiding features in menus. You can't. The mental model is wrong from the start.

An SME-ERP is a different product: shaped around the seven things the business actually does, optimised for speed at the till and clarity at the end of day, with vertical-specific extensions layered on a generic core. Add AI where it suggests; never where it acts. Stay small. Stay fast. Trust that the things you didn't build are the things the customer didn't need.

Done right, this is software that the owner of a shop actually opens every day. Done wrong, it joins the others as "the system we paid for and don't use."