
Rules and ethics
Prove an ecommerce platform keeps Belfast as dispatch origin
Test whether an ecommerce platform keeps Belfast as the dispatch origin for GB and EU orders, from checkout to label, with a six-step demo and records.
A Belfast store can look correct at checkout and still pass the wrong origin to the system that handles the parcel. The test is whether Belfast, as the stock and dispatch location, travels from the product through the order to the label and the records. Ask both suppliers to show that journey on the same order.
The focus is narrow: dispatch origin, order routing, documents and records. The Windsor Framework is relevant to Northern Ireland's goods arrangements, but a platform badge is not evidence that a particular order has been handled correctly.
Start with the dispatch route, not the customer's country
A customer's address tells you where an order is going. It does not tell you where the goods start, which warehouse fulfils them or which movement rules apply. Those distinctions matter when comparing a Belfast store with a setup designed around dispatch from Great Britain.
For this test, use a clearly defined scenario: ordinary physical goods held in Belfast, sold by your business and dispatched directly to the customer. Use Manchester for the GB demonstration and Dublin for the EU demonstration. These are test destinations, not claims about delivery coverage or platform performance.
Keep a separate note of anything outside that scenario:
- Goods dispatched from a warehouse in Great Britain.
- Goods dispatched from an EU warehouse.
- Supplier fulfilment where the supplier chooses the dispatch location.
- Products subject to special controls or product-specific requirements.
- Business customers whose VAT treatment differs from that of consumers.
Do not let a supplier blend those cases into one explanation of "international orders". A demonstration of a GB-to-EU shipment does not establish how the same software handles goods sent from Northern Ireland.
Belfast is not alone in having these considerations: the relevant arrangements apply across Northern Ireland. Describe the stock location as Northern Ireland in the brief, while using your actual Belfast fulfilment address in the test.
Shopify and WooCommerce: who holds the origin?
Shopify and WooCommerce are real alternatives, but they organise the work differently. Shopify is a hosted ecommerce service. WooCommerce is an open-source ecommerce plugin for WordPress, used with a hosting arrangement chosen by the business or its supplier.
That distinction does not prove that either option handles your Belfast orders correctly. It tells you where to start asking questions about configuration, integrations and maintenance. The Shopify and WooCommerce comparison covers the general choice; here the question is only where the Belfast origin is held and who can change it.
| Layer that may hold the origin | Shopify | WooCommerce |
|---|---|---|
| Basic operating model | Hosted ecommerce service | Ecommerce plugin for WordPress, with a separate hosting arrangement |
| Hosting responsibility | Shopify operates the hosted platform | Responsibility depends on your host, managed service and supplier agreement |
| Extending the store | Apps and integrations can form part of the solution | Plugins and integrations can form part of the solution |
| What the demonstration must identify | Platform configuration, installed apps and any external fulfilment service | WordPress and WooCommerce configuration, installed plugins, hosting and any external fulfilment service |
| Who must explain the Belfast route | The supplier proposing the complete Shopify setup | The supplier proposing the complete WooCommerce setup |
Neither column promises a particular built-in tax rule, carrier connection or reporting feature. Those depend on the proposed setup and must be shown rather than inferred from the brand name.
For Shopify, ask the supplier to distinguish the hosted platform from the apps and external services involved in fulfilment. For WooCommerce, ask the same question about the plugin, its extensions and the hosting service. A feature demonstrated through an added component should be recorded as an added component in both proposals.
Managed WooCommerce services can take on work that a merchant would otherwise organise. Equally, a Shopify store can still need someone to maintain its configuration and integrations. Compare the actual division of responsibility, not the shorthand of "hosted" versus "self-hosted". A supplier comparison that sets roles before features follows the same logic.
Give both suppliers the correct Northern Ireland premise
HMRC states that goods sent from Northern Ireland to an EU member state do not need a customs export declaration. Its Northern Ireland goods guidance also explains that Intrastat replaced customs declarations as a source of trade statistics within the EU.
Do not make an export declaration a compulsory output of the Dublin demonstration simply because the destination is outside the UK.
That correction does not mean "no records needed". An order record, sales invoice, carrier label, VAT records and any applicable statistical reporting serve different purposes. A platform supplier should explain which output it is demonstrating and why that output is relevant to your route.
If the proposed integration automatically treats every EU destination as an export from Great Britain, ask the supplier to show how the dispatch origin is represented. Do not assume that it makes this mistake; use the demonstration to establish what it actually does.
A commercial invoice should not be added to the acceptance brief as a universal customs requirement for all Belfast-to-EU parcels. If a carrier or integration asks for a document, ask what purpose it serves and which route the instruction covers. An ordinary sales invoice and a customs document are not interchangeable descriptions.
An EORI number is mandatory for customs operations such as import, export and transit in the EU customs territory, as the European Commission's EORI guidance explains. That does not establish that your Belfast-to-Dublin test needs an export declaration. Determine whether a customs operation exists before making a declaration workflow part of the platform requirement.
VAT needs its own written brief. HMRC operates the VAT One Stop Shop Union scheme for eligible Northern Ireland businesses making qualifying sales of goods to EU consumers, but it is not a blanket instruction for every sale.
Your accountant's confirmed treatment is an input, not something to infer from whichever checkout result looks plausible. The store-journey rule map sets out the other rules that apply along the way.
Run the same six-step origin test on both platforms
Use the same product, stock location, customer type and destinations for both proposals. The sequence configures the demonstration and follows its output. Attach it to the scope sheet for quotes so every supplier prices the same work.
Dual-market setup sequence
- Split shipping zonesGB, NI, EU
- Set destination-based EU VAT rates
- Store commodity codes and origin
- Report distance sales VAT via HMRC
- Run transfer risk assessments
- Test GB and Irish orders
1. Write the order assumptions down
Record the seller, the Belfast dispatch address, the product and whether the customer is a consumer or a business. Add the agreed VAT treatment and identify the fulfilment service expected to receive the order.
Give this brief to both suppliers before the session. If one supplier changes an assumption, record that change rather than comparing its result with an unchanged demonstration on the other platform.
2. Show where dispatch origin is held
Ask the supplier to show how the proposed store identifies the Belfast fulfilment location. Follow that information into the order and any connected dispatch service.
The point is not to insist on a particular menu label. It is to establish whether the correct origin reaches the component that decides how the shipment is handled. A storefront address in the footer is not proof of that connection.
3. Put the GB order through checkout
Use the Manchester destination and inspect the available delivery option, the tax presentation and the order confirmation. Compare them with your agreed brief rather than with an assumed universal UK setting.
Then follow the order towards dispatch. Ask which system receives it, what label or document is produced, and where staff would find an error. A checkout screenshot alone cannot show that the fulfilment hand-off works.
4. Repeat with the EU destination
Use the Dublin destination without changing the Belfast stock location. Inspect the same stages: checkout, confirmation, order record, fulfilment hand-off and document output.
If an export declaration appears, ask the supplier to explain the rule that triggered it. Check for a mistaken GB origin or a generic international-shipping workflow before accepting the output as necessary. Record any unresolved question instead of treating extra paperwork as evidence of compliance.
5. Inspect the records outside the storefront
Ask for a sample order export or report from each proposed setup. Identify the destination, dispatch origin, product, tax information and order identifier needed to reconcile the transaction.
Some information may sit in the platform while other information sits in an accounting or fulfilment system. That can be workable, but the supplier must show the connection. "The accountant can sort it out" is not a demonstrated reporting route.
6. Follow a refund and a changed route
Use a test refund to see what happens to the order, the accounting hand-off and any fulfilment instruction. Do not assume that an attractive returns page demonstrates a working refund process.
Then change the scenario so that the goods would be dispatched from Great Britain rather than Belfast. This is a separate route, not a request for identical treatment. Ask whether the proposed setup can distinguish it and who must review the configuration before that warehouse is used.
Keep a nine-item acceptance record
A comparison becomes useful when the demonstration leaves something you can inspect later. Keep the record alongside the proposal so that an app, plugin or manual step does not disappear between the sales session and the build.
Belfast platform configuration checklist
- Shipping zones splitGB, NI, EU
- Destination-based VAT for EU consumers
- Distance sales VAT reported via HMRC
- Commodity code, origin, value stored
- Commercial invoice attached to EU shipments
- Transfer risk assessment for overseas tools
- DPAs signed with vendors
- Returns policy states customs payer
- Live GB and EU orders tested
- Dispatch assumption:the demonstration identifies Belfast as the stock and dispatch location.
- Customer assumption:the customer type and destination are stated for each test order.
- VAT instruction:the supplier works from your confirmed treatment rather than an unexplained default.
- GB journey:the Manchester order is followed from checkout to the dispatch hand-off.
- EU journey:the Dublin order uses the same Belfast origin and is followed through the same stages.
- Document purpose:each invoice, label or other output has an identified purpose, with no automatic export-declaration requirement for the Northern Ireland-to-EU test.
- Record connection:the order can be traced into the relevant accounting and fulfilment records.
- Change handling:the demonstration shows a refund and identifies what changes when dispatch moves to Great Britain.
- Support ownership:the proposal names who maintains the platform configuration and each connected component.
These are acceptance items for the proposed solution, not a legal checklist covering every product or business model. They also do not prescribe a universal set of shipping zones. Your delivery coverage and fulfilment arrangements should determine the zones you need.
Save the demonstration outputs with the relevant configuration notes. Record which apps or plugins were installed and which external service produced each document. If the supplier later substitutes a component, the affected part of the demonstration needs checking again.
Record differences without inventing a winner
Use a short comparison sheet after the sessions. Put observed results in one column and unresolved questions in another. Avoid turning an unanswered question into a claim that the platform cannot do something.
| Result to record | Evidence to retain | How to interpret it |
|---|---|---|
| Both setups follow the Belfast route as specified | Order records and dispatch outputs | The route does not distinguish the proposals on this demonstration |
| One setup needs an additional component | Component name and the output it supplies | Compare the dependency and who maintains it, not just the platform brand |
| A step is manual | Written procedure and the person responsible | Decide whether the process is workable for your operation |
| A required record cannot be shown | The requested field or output and the supplier's response | Leave that part of the proposal unresolved |
| The supplier changes the dispatch origin | Revised scenario and resulting output | Do not count it as a successful Belfast-origin demonstration |
A manual process is not automatically wrong. It does, however, need a clear owner and instructions, particularly if staff must repeat it for orders on the same route. Conversely, automation is not an advantage when it repeatedly produces the wrong route or document.
For Shopify, your notes should identify whether the demonstrated result comes from the platform, an app or an external service. For WooCommerce, identify whether it comes from WooCommerce, another plugin or an external service. This keeps the comparison about the delivered setup rather than about an assumed feature list.
Do not describe either platform as unsuitable for Northern Ireland on the strength of a supplier's incomplete demonstration. The supported conclusion is narrower: that particular proposal has not yet shown the required journey. Ask for the missing evidence or compare another implementation.
Choose the demonstrated setup, then preserve its boundaries
The better proposal for your business is the one that demonstrates the required Belfast-origin journeys and makes the ongoing responsibilities clear. That could be Shopify or WooCommerce; the hosting model alone does not decide the result.
Keep the decision specific. You are approving a defined product range, fulfilment origin, customer type and set of connected services, not declaring a platform universally compliant with the Windsor Framework. A new warehouse or fulfilment provider can change the route even when the storefront stays the same.
The principle of configuration, not brand is useful here, but configuration needs evidence. Keep the accepted order outputs, the component list and the support responsibilities together. Revisit the affected demonstration when the setup or dispatch route changes.
For a Belfast dual-market store, a convincing supplier does not simply promise "UK and EU support". It shows the Belfast origin travelling through the order, explains the documents produced and gives you records you can reconcile. Those are concrete differences you can compare without mistaking extra customs paperwork for a better platform.
The tool implementation notes cover what to configure once a setup is chosen.
Common questions
Why test dispatch origin rather than the customer's country?
A customer's address tells you where an order is going, not where the goods start or which warehouse fulfils them. Those distinctions matter when a Belfast store is compared with a setup designed around dispatch from Great Britain, so the origin is the thing to follow through the order.
Does a Belfast-to-Dublin order need an export declaration?
HMRC states that goods sent from Northern Ireland to an EU member state do not need a customs export declaration. If a demonstration produces one, ask which rule triggered it and check for a mistaken GB origin or a generic international-shipping workflow before accepting it.
What if a supplier changes the dispatch origin mid-demonstration?
Record it as a revised scenario and do not count it as a successful Belfast-origin demonstration. Changing the origin turns the test into a different route, so compare each supplier only on results that kept the same Belfast stock location and the same destinations.



