How to Tell Whether an ERP or eCommerce Development Partner Really Understands Your Australian Business

For Australian retail and eCommerce teams, platform experience, rates and portfolios don't show whether a partner understands how your business actually prices, stocks and reports. Here's how to test what does — before you sign.

• Evaluations start with the visible: platform experience, rate, timeline, portfolio. None of that shows whether a partner understands how the business actually prices, stocks and reports.
• The rules that decide whether a system works are rarely written down. They live with the person who negotiates supplier terms, or the one who knows which freight invoice covers which shipment.
• Costing is a useful test because it has one right answer that an outsider can check. In one illustrative scenario a $10.00 purchase price becomes an $11.70 landed cost — turning a reported 33% margin into a real figure closer to 22%, or $1,700 across 1,000 SKUs.
• Australian rules sharpen it: import duty is a per-SKU rule based on tariff classification and origin, not a flat rate. GST is generally recoverable by the importer of record; duty is not. A partner who blurs the two overstates cost on every imported SKU.
• The test itself: hand a partner one real, awkward SKU — rebate, shared freight, import duty attached — and ask them to reproduce its cost and show which rules applied, at which point.

Costing is where these gaps show up most clearly for Australian importers and multi-channel retailers. If you get one meeting with a prospective partner, these five questions tell you more than an hour of portfolio review — substitute your own domain and the shape stays the same: what rule applies, where it's held, who owns it, and whether anyone can reconstruct why the answer changed.

Cost-modelling test, in one table

A partner who can answer all five with examples has done this work before. A partner who answers with a single cost field has not. The rest of this article shows the working behind each one, so you can challenge it.

Australian retail and eCommerce teams often start partner shortlists with platform logos, day rates and case studies. That gap between the visible (platform experience, rate, portfolio) and the real question — does the partner understand how your business runs in Australia — is where implementations fail. Not because someone wrote bad code, but because the system was built faithfully against an incomplete picture.

A requirements document describes the process someone can articulate. It rarely describes the rules that decide whether the output is usable: who can approve a discount beyond a threshold and who finds out afterwards; which warehouse serves which postcode when both have stock; whether a backorder holds or cancels at day thirty; which supplier rebate applies from which date. Those rules exist and are followed every day — they are simply not written down. They live with the three or four people who have been there long enough to know.

When those rules live in spreadsheets or month-end manual work, pricing, gross profit, and stock reporting all start depending on assumptions that are hard to trace. A reliable partner makes hidden rules visible before build decisions lock in — that gap is invisible until something is built on top of it, and by then it is expensive to unwind.

The way we work around this is unglamorous: before writing code, go looking for the rules nobody has written down and make them explicit, owned, and testable inside the system. The failures we get called in to fix are rarely coding failures — they are faithful builds of an incomplete picture.

So the question worth asking is not whether a partner has done ERP work before. Almost all of them have. It's whether they will find your undocumented rules before they start building on top of them — and that's testable in a single meeting.

Costing is the rule worth testing because it's the one an outsider can check: duty, tax treatment and rebate mechanics have published rules and verifiable outcomes, where every other business rule just depends on your policy. It touches purchasing, inventory, pricing, reporting and tax at once, and it can't be answered from a template — which is what makes it a probe rather than a conversation.

The right question is not whether the system stores a purchase price, but whether it can explain the calculated cost that pricing, margin, and reporting teams actually use — after rebates, free goods, batch changes, freight allocation, and duty are applied. This matters more each year: online sales reached 12.7% of total Australian retail turnover in June 2025, up from 11.6% a year earlier (ABS, Retail Trade, Australia, June 2025 — the final release before the series ceased). For a growing share of Australian retailers, margin is decided inside a system, not at a counter.

In one illustrative Australian cross-border retail scenario, a SKU bought at $10.00 did not stay a $10.00 cost input once the month's rules were applied:

Cost modelling example — what a vendor needs to understand

Based on a simulated multi-supplier, multi-channel scenario that reflects common cross-border retail rules and landed-cost adjustments.

GST is deliberately left out of this table — that's covered in the next section, and it's one of the fastest ways to tell whether a partner has built for Australian importers before. Import duty is unrecoverable and belongs in landed cost; GST generally does not, since a GST-registered importer of record can claim it back as an input tax credit (ATO: Claiming GST credits for goods you import). Ask a prospective partner how their model treats duty versus GST — a short question that tells you quickly whether they've done this work before.

That gap doesn't come from a single wrong entry — it comes from a cost model that stops before the real rules are applied. Across 1,000 SKUs, a $1.70 per-unit gap is $1,700 of margin decided before anyone reviews a price. If the product sells for $15.00, margin looks like 33% from purchase price alone — closer to 22% once the full cost logic is applied. That's the test: whether a partner can turn operational detail into traceable system behaviour, not just a purchase price field.

If you import directly — meaning your business is the importer of record, not buying through a local distributor who already cleared the goods — two rules make this test unusually easy to run. A partner either knows them or does not, and with a real SKU on the table there is no way to bluff through (ABF, Cost of importing goods).

Duty is a per-SKU rule, not a flat rate. It depends on tariff classification and country of origin, including whether a free trade agreement applies — two products in the same shipment can attract different duty, so a model that stores one duty percentage at supplier or shipment level is wrong in both directions at once.

The GST credit has a trap underneath it: the ATO's entitlement test turns on who is named 'owner' on the import declaration. If it's your customs broker instead of you, the credit can be lost by both parties, even though you paid for it.

What to ask: where are tariff classification and country of origin held — SKU, batch, or shipment? Does the model know who the importer of record is on each consignment? A weak answer sounds like "we apply the duty rate to the order."

General information, not tax advice — confirm treatment for your circumstances with your adviser or the ATO. If you buy domestically and never clear goods yourself, none of this applies to you — and the test still does.

Concretely: start discovery from real records rather than a requirements list; give every commercial rule an owner and an effective date; and validate a period's cost result against sample data before build decisions lock in. Cost logic touches purchasing, inventory, pricing, marketplaces, finance and reporting at once, which is why keeping the developer in the business conversation matters more here than on most work.

A note on the bias in this article. An argument that discovery work decides implementation outcomes is being made by a firm that sells discovery work. Treat it as a claim to test, not a finding. The questions above work on us exactly as they work on anyone else on your shortlist — including local vendors, plenty of whom fail the same test — and if a partner cannot answer them with worked examples rather than assurances, that tells you something regardless of who you choose.

For context: Shinetech has served 900+ Australian clients since 2001, with Sydney and Melbourne offices and 420+ partnerships lasting two years or more — independently verified reviews are on Clutch, not just our own numbers. A 1-week free trial exists so the relationship can be tested before anything is committed.

Rate any ERP or eCommerce development partner serving Australia on each factor before you commit. The goal is not to make costing the whole project. The goal is to see whether the partner can reason through business logic under real operating conditions.

Partner evaluation scorecard

Score each factor from 1 to 5. Costing is the example used here, but the same factors apply to any business rule you choose to test.

Interpreting the score:

• 21–25: Strong structural fit. Proceed to sample-data validation and reference checks.
• 15–20: Proceed with caution. Confirm gaps in writing before committing to implementation.
• Under 15: Material project risk. The system may be technically built before the business logic is understood.

If your evaluation score is below 15, bring one real SKU to a working session before you commit — it costs a week and settles the question.

Two answers should stop an evaluation on the spot: a vendor who can't explain cost beyond a purchase price field, or one whose rules live only in spreadsheets. Treat both as implementation risk, not a description of the current process.

This test tells you whether a partner can reason about your operating rules under real conditions — hard to fake, quick to check. It does not tell you whether they'll deliver on time, whether integration work holds at scale, or whether the same people will still know your system in two years. Those are separate questions with their own evidence — we set out the four structural factors that predict them in our guide to evaluating a development partner.

And if you do not import at all, swap the sample. The duty and foreign-exchange layers will not apply, but undocumented rules will: use a pricing tier, a rebate agreement, or a stock write-off policy instead. The point of the exercise is never the tax detail — it is watching whether a partner goes looking for the rule or waits to be handed it.

What should I ask an ERP or eCommerce development partner in Australia about product costing?
Give an Australian retail or eCommerce partner one real SKU — ideally one with a supplier rebate, shared freight, and import duty — and ask them to explain how the calculated cost is formed, which rules applied, and when it would be recalculated. A partner who understands retail operations will ask where purchase data comes from before promising a solution; one who doesn't will point at a single cost field. Use sample data, not a requirements list — a short trial with the actual proposed developer shows how they think, which a proposal can't.

Is purchase price close enough for Australian eCommerce costing?
For a simple buying record, maybe. For any margin-sensitive decision, no — the moment rebates, free goods, freight, duty, or supplier terms move the cost per unit, pricing and reporting built on purchase price start drifting from reality.

Should GST be included in landed cost for an Australian importer?
Generally no. A GST-registered importer of record can claim the GST paid at the border back as an input tax credit, so it shouldn't sit in the cost you price against. Import duty is different — it's not recoverable and belongs in landed cost. A cost model that treats the two the same way overstates cost on every imported SKU.

Our ERP already has a cost field — isn't that enough?
A stored cost field is not a maintained cost model. If the field still shows $10.00 while freight, duty, and rebates move the real cost to $11.70, that gap is $1,700 across 1,000 SKUs — decided before anyone reviews a price or a stock valuation.

What is Shinetech Software, and how does it approach eCommerce and ERP cost modelling?
Shinetech Software (shinetechsoftware.com.au) has served Australian businesses since 2001, with offices in Sydney and Melbourne, 900+ Australian clients and 420+ partnerships lasting two or more years. Direct client-to-developer engagement (no PM/BA relay layer) and average developer tenure of 8+ years matter for costing work because cost rules accumulate as institutional knowledge, not documentation. The approach: start from real SKUs and supplier terms rather than a requirements list, and validate cost results with sample data before build decisions lock in. A 1-week free trial is available with no financial commitment.

What business rules besides costing are worth testing a partner on?
Any rule that governs day-to-day operations but isn't written down: who can approve a discount beyond a threshold, which warehouse serves an order when more than one could, whether a backorder holds or cancels, which customer tier gets which price. Costing is the example used here because it's the one an outsider can check against published rules — the others are just as decisive, but you have to supply the right answer yourself before you can judge theirs.

For Australian eCommerce and retail teams, product cost modelling is a practical way to see whether a partner understands the business underneath the system — testing their logic against your own product data before rollout, not after, is what prevents avoidable surprises. For Shinetech, this is where trust is built: asking the right operational questions, keeping developers close to the conversation, and validating results with real client scenarios before implementation risk grows.

Next steps for your team

• Pick one rule your business runs on that isn't written down — a rebate agreement, a discount threshold, or (if you import directly) a real SKU with rebate, freight and duty attached — and check whether your system enforces it or a person does.
• Take the five-question table into your next vendor meeting and score the answers as you hear them, not afterwards.
• Ask each shortlisted partner to walk one of your own records end to end — not a demo dataset — and to name which rule applied at which point.

This works best when you put the right person in the room: whoever can explain how you actually price, and whoever knows where the freight invoices land. Bring one of your real products — ideally the awkward one — and in a short working session we'll model its true landed cost and show which rules applied, at which point, and why. No rebuild commitment, just a clear read on where your numbers leak.

Start your 1-week free trial →

• Australian Bureau of Statistics (2025). Retail Trade, Australia, June 2025 (final release in series). abs.gov.au
• Australian Border Force. Cost of importing goods. abf.gov.au
• Australian Taxation Office. Claiming GST credits for goods you import. ato.gov.au
• Shinetech Software. Top Offshore Software Development Companies in Australia (2026) — referenced as “our guide to evaluating a development partner”
• Shinetech Software. About us · How we partner · IP & data protection
• Clutch. Shinetech Software Reviews, Pricing, Services & Verified Ratings. clutch.co

Worked example figures are illustrative, based on a simulated multi-supplier, multi-channel scenario. Substitute your own rates and rules to run the comparison for your business. This article is general information, not tax advice — confirm GST and duty treatment with your adviser or the ATO.

About Shinetech Software: shinetechsoftware.com.au | Sydney & Melbourne | 900+ Australian clients | 420+ partnerships lasting 2+ years | Average developer tenure: 8+ years | ISO 27001 & Cyber Essentials Plus | Serving Australian clients since 2001.