For wholesalers and brands with reps on the road

Field Sales Rep Ordering: Getting Orders From the Tablet Into the ERP Intact

Your reps visit pharmacies in regional Queensland, hardware stores in the outer suburbs, cafes on a Tuesday run and a stand at a trade show twice a year. They take orders on a tablet or phone, often with patchy reception, and those orders need to land in your ERP as sales orders with the right customer, the right price, the right delivery date and nothing for the office to retype.

The ordering app is usually the easy part. The integration behind it decides whether the rep can trust what the screen says when the signal drops, whether a show special or a forward order survives the trip into MYOB Acumatica, MYOB EXO, NetSuite, Business Central, Cin7 or Unleashed, and whether head office ends up approving, fixing or re-entering half of what the reps send in. This page covers the mechanics, the failure modes and when an off-the-shelf app with a native connector is all you need.

Book a Rep Ordering Call (03) 9003 0111

Rep Ordering by the Numbers

5 data sets

A rep needs on the device before leaving the depot

Customers, their prices, stock indication, order history and account status. Miss one and the rep phones the office

3 order types

Commonly taken by wholesale reps

Immediate orders, indent or forward orders for a future season, and trade show orders with their own pricing. Your mix may differ

Hours to days

A rep may work offline before syncing

Varies widely by territory. Regional runs and show halls are where offline design gets tested

0 rekeyed lines

The target for orders reaching the ERP

A structural goal, not a promise. Exceptions still happen, the design decides whether they are queued or retyped

Four Things That Decide Whether Reps Trust the App

A rep who does not trust the app goes back to a paper order pad or a photo of a handwritten list. These four design choices are what earn that trust.

The price on the screen is the price on the invoice

Reps quote from the app in front of the buyer. If the app calculates a different price from the ERP because the price list, the customer price group, a contract price or a quantity break was copied across badly, the office either honours a wrong price or calls the customer to explain. The app should either receive prices calculated by the ERP for each customer, or apply exactly the same rules from data the ERP owns, never a separately maintained list.

It works with no signal

Pharmacies in shopping centres, hardware stores with steel roofs, country towns and exhibition halls with four thousand people on the same network all defeat mobile data. The app has to hold everything the rep needs locally, accept orders offline, and sync cleanly later. An app that has to fetch the price list while the rep is with the buyer slows the order down, and some buyers will not wait.

Orders arrive as real sales orders

An emailed PDF from the app to the sales inbox is not integration. The order should be created in the ERP as a sales order against the correct customer account, with the rep, territory, price, delivery date, order type and any approval status set, so warehouse picking can start without anyone touching it.

The rep knows when to stop

A rep who takes a large order from an account on credit hold, or offers a discount beyond their authority, creates a problem for the office and an awkward conversation for the customer. The app needs to show account status and outstanding invoices, and enforce discount limits with a clear approval path, so the rep can handle it on the spot rather than discover it a week later.

How a Rep Ordering Integration Actually Works

Six mechanisms sit between the tablet and the ERP. Each one has a decision behind it that should be made deliberately.

Device catalogue

The offline data set

Before a rep leaves, the device needs the customers assigned to them, each customer price or price group, product catalogue with images and pack sizes, a stock indication, the last few orders per customer and account status including credit hold and overdue balance. The integration builds this from the ERP on a schedule, usually a full refresh overnight and small deltas through the day when signal allows. Scope it by territory so a rep is not carrying the whole customer file, which matters for both sync speed and privacy.

One price logic

Pricing parity

The ERP stays the owner of price. The two workable approaches are pushing a calculated net price per customer and product to the app, or pushing the pricing building blocks (price lists, customer groups, contract prices, quantity breaks, promotions) and having the app apply the same rules. The first is simpler and safer for modest catalogues. The second scales to large catalogues but needs testing against the ERP for a sample of customers every time a pricing rule changes.

Clean merge

Offline sync and conflict

When an order taken offline syncs, things may have changed: the price was updated overnight, the item sold out, the customer went on hold. The integration needs a rule for each. A common pattern: keep the price the rep quoted if it was valid when the order was taken and within a tolerance, flag the line if stock is no longer available rather than silently dropping it, and hold the order for credit review if the account status changed. The rep gets a clear notification of anything altered.

Correct order class

Order types and dates

An indent or forward order for next season is not an immediate order. It needs a requested delivery date or delivery window, often a different order type or warehouse in the ERP, sometimes split deliveries across months, and it must not reserve current stock. Trade show orders carry a show code, show pricing and often extended terms. The integration maps each app order type to the ERP order type, so planning and purchasing see the forward book separately from today.

Approval queue

Approvals and exceptions

Orders that break a rule, such as a discount beyond the rep limit, an account on hold, a minimum order value not met or a product the customer is not allowed to buy, are created in the ERP on hold with a reason, or held in the integration layer for a sales manager to approve from a phone. The rep sees the status change. Nothing gets silently released and nothing gets silently lost.

Visit record

Everything around the order

Visit notes, shelf and planogram photos, competitor observations, a customer signature on the order, and the call itself as a logged activity. These belong in the CRM or the customer record, not in the sales order. The integration routes each one to its proper home and links it to the customer and the order reference, so the account manager can see the visit history without opening the ordering app.

Rep Ordering Situations and How They Should Be Handled

Task	Traditional	Done Properly	Notes
Pharmacy order with no signal	Rep writes it down, enters it that night	Taken offline, syncs when back in range	The rep sees a pending status on the device until the ERP confirms the sales order number, so nothing is assumed to have arrived.
Price changed while the rep was offline	Office notices on the invoice, customer queries it	Sync rule applies the agreed price policy	Example policy: honour the quoted price for orders taken within 24 hours of the change, flag anything older for the sales manager.
Item sold out before the order synced	Warehouse short ships without telling anyone	Line flagged as backorder or substitute offered	Whether to backorder, cancel the line or suggest a substitute is a customer level setting, agreed with sales, not a guess.
Indent order for spring range	Spreadsheet kept by the rep, keyed in later	Forward order with delivery window in the ERP	Feeds purchasing with real committed demand by month, which is often the main reason wholesalers invest in this.
Trade show order with show special	Paper forms batched after the show	Show price list and code applied in the app	Show pricing is published to the app for the show dates only, and the show code lets you measure what the show actually produced.
Discount beyond rep authority	Rep phones the manager, or just gives it	Order held, manager approves from a phone	Example limits: up to 5 percent at rep discretion, 5 to 10 percent needs a manager, beyond that needs a director.
Hardware store on credit hold	Order taken, then blocked in the office	Rep sees hold and overdue invoices on arrival	The rep can collect a payment or a promise to pay during the visit, which is far better than an awkward call later.
Cafe owner signs on the tablet	Signed carbon copy lost in the van	Signature stored against the order	Useful for disputed deliveries or terms acceptance. Store it with the order record, not in the rep photo roll.

Where Rep Ordering Integrations Go Wrong

Prices maintained in the app as well as the ERP

It starts as a convenience: someone uploads a price spreadsheet to the app because the connector did not handle contract prices. Six months later the two drift and reps are quoting prices the ERP will not produce. Keep the ERP as the single owner of price and have the integration publish to the app. If your B2B portal also exists, it must use the same price logic, otherwise customers compare the portal against what the rep offered.

No rule for what changed while offline

Without an explicit conflict policy, the default is whatever the developer chose, often last write wins or a silent rejection. Agree with sales and finance what happens to price changes, stockouts, deleted products and credit holds on orders taken offline, write it down, and test each case by putting a device in flight mode before go live.

Duplicate orders from a nervous rep

A rep who cannot see whether an order went through will submit it again. The app should give each order a unique reference created on the device, and the integration should use it so a resubmitted or retried order updates the original instead of creating a second one. This is a common cause of double deliveries after go live.

Forward orders reserving current stock

If indent orders for next season land as ordinary sales orders, they can allocate stock on hand today, starving immediate orders and confusing purchasing. Map them to a separate order type, warehouse or future dated status that your ERP treats as demand, not as a current allocation, and confirm how your specific ERP handles that before building.

A lost tablet carrying the customer file

A rep device holds customer names, contacts, pricing and account balances. Under the Privacy Act 1988 and the Australian Privacy Principles you need reasonable steps to protect personal information. Use device management with a passcode, encryption and remote wipe, give each rep their own login rather than a shared one, scope data to the territory, and revoke access the same day a rep leaves.

Territory changes that nobody syncs

Customers move between reps when territories are reshuffled or someone resigns. If the assignment lives only in a spreadsheet, the new rep cannot see the account and the old one still can. Hold territory and customer assignment in one place, usually the ERP or CRM, and let the integration drive what each device receives and which rep is recorded on each order for commission.

How Yes AI Approaches Rep Ordering Integration

App fit check before anything is built

Many rep ordering apps have a native connector for Cin7, Unleashed, MYOB Acumatica, NetSuite or Business Central that already handles customers, products, price lists and sales orders well. If yours covers your pricing and order types, we will say so and help you configure it rather than build something custom. We build only the parts the connector does not handle.

Pricing and conflict rules agreed first

We document price ownership, the offline conflict policy, order type mapping, discount authority levels and credit hold behaviour with your sales and finance people, and test them against real customers and real price lists before any rep sees the app.

Built, hosted and monitored

The integration runs on a managed cloud automation layer we operate, with record level logging of every order from device reference to ERP sales order number, alerting when orders stall, and a replay process for anything that failed. You do not maintain scripts or servers.

An exception queue the office can work

Orders that need approval or could not be created land in a short queue with the reason attached, so a sales coordinator reviews a handful of orders a day instead of retyping all of them. Reps see the outcome on their device.

How a Rep Ordering Integration Gets Delivered

Staged so reps get a working app early, with the harder order types added once the basics are proven in the field.

Ride along and map the order flow

We look at how reps take orders today, the order types, the pricing structures, the approval rules and what the office does when an order arrives. We confirm what your ERP and any chosen app support natively, and identify the gaps that actually need building.

Agree ownership and rules

Price ownership, offline conflict policy, discount authority, credit hold behaviour, order type mapping, territory assignment and where notes, photos and signatures belong. Written down and signed off by sales and finance.

Build the core flow

Customer and product publishing, pricing, stock indication and account status out to the app, immediate orders back into the ERP as sales orders. Tested with real customers, real prices and devices in flight mode.

Pilot with two or three reps

A small group runs live territories for a few weeks, including at least one regional run. We watch every order through to the ERP, fix mapping issues and tune the conflict rules before the wider rollout.

Add forward orders, shows and approvals

Indent orders with delivery windows, trade show price lists and codes, the discount approval path and the visit record routing to CRM, then a full rollout with monitoring and a documented support process.

FAQ

Do we need a custom integration, or will an off-the-shelf rep ordering app do?

Often an off-the-shelf app with a native connector to your ERP is the right answer. If the connector handles your customer pricing structure, your order types and your account status, configure it and move on. Custom integration earns its place when your pricing is complex (contract prices, quantity breaks, promotions by buying group), when you need indent orders with delivery windows mapped to a specific ERP order type, when you need approvals outside the app, or when visit notes and photos need to reach a CRM the app does not support. Check the connector against those specifics before you buy.

Which ERPs can a rep ordering app connect to?

Most common Australian wholesale systems can be connected, including MYOB Acumatica, MYOB EXO, NetSuite, Dynamics 365 Business Central, Cin7 and Unleashed. The cloud systems offer modern APIs. MYOB EXO is usually on premises or privately hosted, so the connection is often made through its API service or a database integration, which needs care around hosting and access. The ERP matters less than how your pricing and order types are configured in it.

What happens if a rep takes an order offline and the price changes before it syncs?

That depends on the policy you set, which is why the policy needs to exist. A common approach is to honour the price the rep quoted if the order was taken before the change and within an agreed window, and to flag the order for review if the gap is larger or the change was a correction of an error. The integration records both the quoted price and the current ERP price so the office can see exactly what happened.

How do indent or forward orders work in an integration?

The app captures a requested delivery date or window, sometimes split across several deliveries. The integration creates the order in the ERP as the appropriate order type or future dated order so it is visible as committed demand for purchasing, but does not allocate current stock. Each ERP handles this differently, so the mapping is confirmed against your configuration rather than assumed.

Can the rep app and our B2B portal run side by side?

Yes, and many wholesalers want both: the rep handles relationships, new ranges and larger orders, the portal handles routine top ups. The rule is that both must draw prices, stock indication and account status from the same ERP logic, and both orders should be attributed correctly so the rep is credited where your commission rules say they should be. Otherwise customers notice the portal and the rep quoting different numbers.

Can the app show reps their commission?

It can show sales by rep, territory and customer, which is usually what reps want during the month. The commission calculation itself is better done in one place with clear rules for returns, credits and shared accounts, and then published to the app or a report. The integration makes sure every order carries the right rep and territory so that calculation has clean data to work from.

What should we do about device security?

Treat rep devices as carrying sensitive customer and commercial data. Use mobile device management with enforced passcodes, encryption and remote wipe, individual logins for every rep, territory scoped data rather than the whole customer file, and a same day offboarding step that revokes app and integration access. Confirm where the app vendor stores data and how long, as part of meeting your obligations under the Australian Privacy Principles.

Get Rep Orders Into the ERP Without Rekeying

Book a call. We review how your reps order today, check whether your app or ERP connector already covers it, and give you a clear plan and price for anything that needs building.