For Australian retailers and wholesalers running Maropost or Neto

Maropost Commerce Integration: Connecting a Platform That Is Half an ERP

Maropost Commerce Cloud began life as Neto, a platform built in Australia for Australian merchants, and it shows. Out of the box it handles inventory across warehouses, purchase orders, customer groups with their own pricing, wholesale accounts, marketplace listings and point of sale, as well as the web store. That breadth is why many retailers and wholesalers chose it. It is also why integrating it is different from integrating a pure storefront.

When a platform already manages stock, pricing and purchasing, connecting it to an ERP, a 3PL or a separate accounting system starts with a question most integration projects skip: which system owns what. Get that wrong and Maropost and the ERP spend their days overwriting each other. This page covers the ownership decisions, the flows that matter, when the built in accounting links are enough, how the API behaves in practice, and how to decide whether to integrate around Maropost or move off it.

Talk Through Your Maropost Stack (03) 9003 0111

Realistic ROI

1 owner

Per data type, decided up front

Stock, price, product, customer and purchase order each need exactly one

2 roles

Storefront only, or operational hub

Maropost can be either, and the integration design depends on which

2 to 6 weeks

For a single well scoped flow

A typical range from scoping to live, longer for full ERP replacement of native features

AUD, ex and inc GST

Pricing bases to reconcile

Whether prices are stored GST inclusive must match what the ERP and ledger expect

Four Decisions That Shape Every Maropost Integration

Each of these is a business decision with technical consequences. Make them before any field is mapped.

Who owns stock

Maropost can hold stock levels per warehouse and adjust them from orders, receipts and stocktakes. So can your ERP, your 3PL and your point of sale. Only one should be the source of truth for available quantity, with the others reading from it. For a business with an ERP or a 3PL, that is usually the ERP or the warehouse system, and Maropost becomes a consumer of stock levels rather than the ledger of them.

Who owns pricing and customer terms

Customer groups, price levels, quantity breaks and wholesale accounts are among the reasons wholesalers choose Maropost. If the ERP also holds customer specific pricing and credit terms, two sets of price rules will drift apart. Decide which system is the price authority for trade customers, and push prices one way only, including the GST basis prices are stored on.

Who owns purchasing

Maropost includes purchase orders and supplier records, which suit a business without an ERP. Once an ERP or inventory system is introduced, running purchasing in both creates competing on order figures and duplicate receipts. Most businesses with an ERP move purchasing there entirely and keep Maropost focused on selling, but the transition needs planning so open purchase orders are not lost.

Storefront or operational hub

Some businesses run Maropost as their operational core, with accounting as the only other major system. Others use it purely as the storefront in front of an ERP. Both are legitimate. The mistake is drifting into a halfway state where some warehouses, some customers and some purchasing live in each system, because then every integration flow has to handle both cases.

The Flows That Matter in a Maropost Stack

Six flows cover most Maropost integrations. Which way each one runs depends on the ownership decisions above.

Orders where they ship from

Orders out to fulfilment

Paid orders from the web store, wholesale accounts and connected marketplaces sent to the ERP, warehouse system or 3PL with the fields each needs: delivery instructions, shipping method, customer reference and line level warehouse allocation. Fulfilment status, tracking numbers and dispatched quantities come back to Maropost so customer notifications and marketplace updates fire from one place.

Available quantity per warehouse

Stock levels in

Available stock pushed from the system that owns it to Maropost per warehouse, frequently for fast moving lines and less often for the long tail. Safety buffers applied for marketplaces with slower updates. Changes are sent as differences where possible rather than full catalogue refreshes, which keeps API traffic sensible for larger catalogues.

One catalogue, one price authority

Products and pricing

Product master data, variants, kits and price levels flowing from the owning system, which may be the ERP, a PIM or Maropost itself. Parent and child relationships and custom fields mapped deliberately so web content edited in Maropost is not overwritten by bare ERP descriptions, while commercial fields such as cost, price and tax code stay controlled by the ERP.

Customers matched across systems

Customers and trade accounts

Retail customers created in Maropost and matched to the ERP or accounting system where invoices need a debtor record. Trade accounts with credit terms, price groups and account managers synchronised from the system that owns them, including account holds, so a customer stopped for credit in the ERP cannot keep ordering online.

Ledger that reconciles

Accounting and settlement

Invoices or daily summaries posted to Xero, MYOB or the ERP ledger with correct GST codes, payments matched by method, and gateway, marketplace and buy now pay later settlements reconciled with fees separated. For many smaller merchants the built in accounting connection does this adequately and the work is in configuring it well rather than replacing it.

Failures seen same day

Events and monitoring

Maropost’s event notifications used to trigger flows when orders, products or stock change, backed by a scheduled sweep that catches anything a notification missed. Every flow logged at record level, with alerts when an order fails to reach fulfilment, a stock update is rejected or a price push does not complete.

Typical Maropost Integration Work

Task	Traditional	Integrated Properly	Notes
Maropost plus Xero or MYOB	Built in link, loosely configured	Built in link, configured properly	Often no custom build is needed. Tax codes, payment mapping and summary versus detail posting are where the value is.
Adding an ERP behind Maropost	Stock and pricing in both	ERP owns stock, price and purchasing	Maropost keeps selling, marketplaces and web content. Purchasing moves to the ERP with a planned cutover.
Moving warehousing to a 3PL	Orders emailed or exported	Orders and stock synced with the 3PL	Stock on hand from the 3PL becomes the source of truth for that warehouse in Maropost.
Wholesale portal pricing	Price groups kept by hand	Pushed from the price authority	Customer specific contract prices are the most error prone data in most wholesale stacks.
Stores and web together	Separate stock pools	One available figure per location	Whether the stores use Maropost POS or another POS, stock must come from one owner.
Marketplace orders	Handled in a separate tool	Through Maropost to fulfilment	Keeps one order flow and one stock pool, with marketplace specific buffers.
Marketing platform sync	CSV exports of customers	Customers, orders and consent synced	Consent status has to travel with the customer, not just the email address.
Considering a replatform	Decided on features alone	Decided on integration cost too	The integrations you would rebuild are a large part of the true cost of moving.

Where Maropost Integrations Go Wrong

Native features left switched on

When an ERP takes over stock or purchasing, Maropost features that also adjust stock or raise purchase orders need to be reviewed and, where appropriate, turned off or restricted. Otherwise a stocktake in Maropost or an auto generated purchase order quietly contradicts the ERP. Document which native features remain in use.

GST basis mismatches

Maropost, the ERP and the accounting system may each store prices GST inclusive or exclusive, and may round differently. A mismatch shows up as one cent variances on invoices and a growing reconciliation headache. Decide the basis, confirm the rounding approach, and test invoices with multiple lines, discounts and freight before going live.

Over relying on event notifications

Event notifications are the right trigger for timely flows, but any notification system can delay or drop an event. A scheduled sweep that compares recent orders and stock changes against what the integration processed catches the gaps. Without it, missing orders are found by customers.

Ignoring API limits on large catalogues

Full catalogue refreshes of tens of thousands of SKUs can be slow and may run into API limits, especially when several apps call the API at once. Use changed records only, schedule bulk work outside trading peaks, and confirm current limits and pagination behaviour against Maropost’s documentation rather than assumptions.

Losing open documents at cutover

Moving purchasing, customer pricing or stock ownership from Maropost to an ERP mid trade means open purchase orders, partially received deliveries, backorders and layby or deposit orders have to be carried across deliberately. Plan the cutover date around your trading calendar, not in the run up to a peak.

Privacy across connected systems

Every flow that moves customers to an ERP, a 3PL or a marketing platform creates another copy of personal information. Under the Privacy Act 1988 and the Australian Privacy Principles, where they apply to you, you should know where each copy lives, send only the fields each system needs, and make sure your privacy policy reflects the systems customers’ data actually reaches.

How Yes AI Approaches a Maropost Stack

Ownership decided in writing

We work through stock, pricing, product, customer and purchasing ownership with your team and record the decisions, including which native Maropost features stay on. That document becomes the specification.

Native links first

If the built in accounting connection or an established add on covers your needs, we configure it properly and tell you so. Custom integration is reserved for the flows that genuinely need it.

Built, hosted and monitored by us

Custom flows run on a managed cloud automation layer we operate, with record level logs, a scheduled sweep behind every event driven flow, and same day alerting.

Straight advice on stay or move

If you are weighing a replatform, we lay out the integration work either path implies. We have no stake in which platform you choose, only in the stack working.

From Tangled Stack to Clear Ownership

Five steps. A first flow is typically live in two to six weeks. Moving ownership of stock or purchasing to an ERP is usually a planned project of two to four months.

Map the stack and native features

Every system, every Maropost feature in use, every add on and every manual workaround, with how data actually moves today.

Decide ownership

One owner per data type, the role Maropost plays, and the native features to keep, restrict or retire.

Specify flows

Triggers, fields, direction, matching rules, GST basis and exception handling for each flow, in plain English your team can check.

Build, test and cut over

Built against the API, tested on a copy of real data including awkward orders, then cut over on a date chosen around your trading calendar.

Monitor and extend

Same day alerting, monthly review of exceptions, then further flows such as marketplaces, marketing and supplier feeds.

FAQ

Is Maropost Commerce Cloud the same as Neto?

Yes. Neto was an Australian ecommerce platform that was acquired by Maropost and renamed Maropost Commerce Cloud. Many merchants and developers still call it Neto, and parts of the API and documentation still use the Neto name. Integration approaches that worked with Neto generally still apply, though you should always check the current documentation for changes.

Do we need custom integration to connect Maropost to Xero or MYOB?

Often not. Maropost has built in accounting connections, and for many smaller merchants a well configured native link is the right answer. Custom work becomes worthwhile when you need settlement reconciliation by payment method, multi entity posting, non standard GST treatment, or when an ERP sits between Maropost and the ledger. We will tell you which side of that line you are on.

Should Maropost or our ERP own inventory?

If you have an ERP or a 3PL warehouse system, usually that system. Maropost then receives available quantities per warehouse and stops being the ledger of stock. If Maropost is your operational core and you have no ERP, it can own inventory perfectly well. What matters is that exactly one system does, and that native stock adjusting features in the others are reviewed.

How does the Maropost API work?

The API accepts requests that name an action, such as retrieving or updating items, orders or customers, authenticated with an API key, and the platform can send event notifications when records change. In practice the important design choices are using changed records rather than full refreshes, backing notifications with a scheduled sweep, and respecting limits on large catalogues. Confirm specifics against the current Maropost documentation.

Can Maropost handle wholesale and retail in one store?

It is one of its strengths, through customer groups, price levels and trade accounts. The integration question is where those prices and terms are maintained. If the ERP is the price authority for trade customers, prices and account holds should flow from it to Maropost one way, so the web store never offers terms the ERP would not.

Should we stay on Maropost or move platforms?

That depends on your requirements, and features are only part of it. If Maropost is doing operational work such as purchasing, multi warehouse stock and wholesale pricing, a move means replacing those functions somewhere else as well as rebuilding every integration. Sometimes that is still the right call. Price the whole picture, including integrations and data migration, before deciding.

How long does a Maropost integration take?

A single, well defined flow such as orders to a 3PL with tracking back is typically two to six weeks from scoping to live. Moving ownership of stock, pricing or purchasing from Maropost to an ERP is a larger planned project, often two to four months, because open documents and native features have to be handled carefully and the cutover timed around trading.

Get Your Maropost Stack Working as One System

Book a call. We map how your Maropost store connects to everything else, recommend clear data ownership, and give you a priced plan. The map and recommendations are yours either way.

Book a Maropost Integration Call (03) 9003 0111

All discussions held in confidence. Australian-based consultants.