Buying Operations Software in Namibia: A Straight Guide
A small market with a thin local bench, a serious South African vendor presence, and one statutory rule that almost nobody's system applies. Here is how to score the shortlist, including us.
Namibia is a small market and that shapes the software decision more than any feature comparison will. There is a thin local implementation bench, a substantial and competent South African vendor presence, and a habit — entirely rational — of doing serious systems work in-house.
So the useful questions here are not about capability. They are about who answers when something breaks, and about one specific rule that separates systems which understand Namibian importing from systems which do not.
The question that sorts the shortlist in one minute
Ask any vendor: what value does your system use for import VAT on a purchase from South Africa?
The right answer involves the statutory valuation — the greater of FOB plus ten per cent, or open market value — and an explanation of where that number lives in the system. A wrong answer is "the invoice value". An informative answer is "I don't know, let me check", which at least tells you they will not invent one.
Why this question works so well
It is narrow enough to have a right answer, specific enough that it cannot be bluffed with a feature name, and consequential enough that getting it wrong understates the landed cost of every import you have ever recorded. It also tells you something more general: whether the vendor has ever actually implemented for a Namibian importer, or is describing a South African product with the country name changed.
A vendor who has genuinely worked here will know about the uplift. One who has not will tell you confidently that VAT is calculated on the invoice, and will be wrong in the same direction every time.
The support question, which is the bigger one
In a market of this size, the difference between vendors is rarely the feature list and almost always what happens on an ordinary difficult afternoon. Ask it directly and ask it of everybody, including any vendor you are inclined to favour.
Five support questions and what the answers mean
Who answers on a Tuesday afternoon when a receipt will not post?
What a good answer sounds like
A named channel, a location, stated hours and a language. Remote is fine if it is stated.
What a weak answer tells you
A generic support address with no hours, or a reseller two countries away who "usually responds quickly".
What happens if the person who implements our system leaves your company?
What a good answer sounds like
A documented configuration, a second person who knows the account, and a handover practice that exists before it is needed.
What a weak answer tells you
Reassurance about staff retention. That is not an answer, and in a small market it is the risk that actually materialises.
How many Namibian customers do you have, and can we speak to one?
What a good answer sounds like
A number, honestly, even if it is small, and a willingness to make an introduction.
What a weak answer tells you
A regional figure offered instead of a country one. "Southern Africa" is not Namibia.
What does it cost to change something after go-live?
What a good answer sounds like
A rate, a process, and an honest statement of what is configuration versus development.
What a weak answer tells you
Vagueness. Post-go-live change is where small-market implementations quietly become expensive.
What are you not good at here?
What a good answer sounds like
Two or three specific gaps, named without prompting.
What a weak answer tells you
Nothing. Every product has gaps and a vendor unable to name theirs has either not thought about it or will not tell you.
What each kind of vendor is actually good at
Written as fairly as we can manage given that we are one of the three. If your requirement points to a column that is not ours, buy from that column.
| Where it fits | Where it does not |
|---|---|
| A South African vendor with a consultant who visits. Deep local product knowledge, a real bench, familiarity with SARS and SACU trade, and somebody in the room during implementation | Namibian specifics are sometimes treated as a variation on South Africa. Travel is a real cost line, and it is the first thing cut when a project runs long |
| Building or extending in-house. Perfect fit, complete control, and nobody understands your business better | It becomes one person's system. The risk is not technical competence, it is that the knowledge is not shared and the person eventually leaves |
| A remote regional vendor, which is us. Built for imported stock, multi-site operations, poor connectivity at remote sites and landed-cost discipline — and one hour off your working day | No office here, no local implementation partner, and no statutory filing or payroll. In a market that values a face in the room, that is a genuine disadvantage rather than a detail |
Where we fit and where we do not
What we do here today
- Landed cost on the consignment, with cost components you define allocated to the receipt and carried into unit cost.
- Order, receipt and invoice matched, with discrepancies raised rather than absorbed.
- Per-site stock and confirmed transfers, so goods in transit belong to somebody and a short delivery surfaces against the dispatch.
- NAD and ZAR stored as distinct currencies even at par, with the rate actually applied retained.
- Approvals that block above a threshold, per site, with a complete audit trail.
- Mobile capture at remote sites, including where the connection is poor.
What we do not do — including the one that limits our own argument
- We do not maintain the import VAT valuation rule as a built-in calculation. You can model the uplift as a cost component so the number exists in your landed cost. You configure it, you own it, and you check it with your accountant.
- No NamRA integration. No filing, no return preparation, no ITAS connection, no advice on your registration position.
- No Namibian payroll. No PAYE tables, no Social Security Commission contributions, no VET Levy.
- No customs or clearing integration. No ASYCUDA connection and no data link to your agent.
- No mining-specific compliance. No royalty computation and no statutory mining returns.
- No local office and no Namibian implementation partner. Support is remote from Nairobi, in English, one hour ahead.
What is not built for Namibia today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Namibia. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If NamRA filing output, a Namibian payroll engine, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
NamRA output and the import VAT valuation rule
VAT return output in the shape NamRA expects, and — the piece specific to this market — the statutory import valuation applied as a rule rather than as a habit, so the taxable value of an import is derived rather than assumed to equal the supplier's invoice. That rule catches SACU purchases hardest, because there is no duty and no broker involved to make anybody notice it.
Banks, EFT and cross-border settlement
Bank statement feeds, EFT and debit-order files and card acquirer settlements pulled into the Payments Register, including the South African side of a supplier relationship that settles at par but still crosses a border.
Payroll and statutory returns
PAYE on the Namibian tables, Social Security Commission contributions and the VET Levy, computed on live records and produced in the layout each body expects.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedA scorecard weighted for this market
Generic ERP scorecards have no row for the two things that decide this decision, which is why they produce the wrong answer here.
Five criteria, weighted for Namibia
Score each vendor out of the weight shown, on evidence rather than claims.
Support reality
Make them prove it: Who, where, what hours, and what happens when your implementer leaves.
Import treatment
Make them prove it: What value do you use for import VAT on a South African purchase?
Landed cost
Make them prove it: Produce the true landed cost of one consignment including everything paid to have it.
Distance discipline
Make them prove it: How does a count at a site 700km away get recorded and reconciled?
Named gaps
Make them prove it: What are you not good at here?
One thing to do before any demonstration
Take one import from South Africa and compare the supplier invoice against the value your current system used for import VAT. If they are the same, you have found something worth an hour of your accountant's time, and you found it without buying anything. If they differ correctly, your process is in better shape than most and you can weight the rest of this scorecard towards support instead.
Either outcome is a good outcome. The one thing that would be a waste is going into a vendor conversation without knowing which of the two you are.
