Distribution ERP software brings together the operational and financial processes used by wholesalers, distributors and other inventory-led businesses.
That can include:
- sales orders;
- customer accounts;
- inventory;
- warehousing;
- purchasing;
- dispatch;
- invoicing;
- credit control;
- payments; and
- financial reporting.
For payments, the important question is not simply whether an ERP can connect to a card gateway.
It is whether payment activity fits the wider order-to-cash process.
For example:
sales order → payment or credit terms → fulfilment → invoice → collection → settlement → reconciliation.
A well-designed payment integration can reduce the need for staff to re-key transaction information, manually match payments to orders or invoices, and move between disconnected systems.
This guide focuses specifically on payment integration for wholesale and distribution ERP environments.
What is a distribution ERP?
A distribution ERP is an Enterprise Resource Planning system designed around businesses that buy, hold, sell and distribute physical goods.
Compared with a more general finance or accounting platform, a distribution-focused ERP may place greater emphasis on:
- inventory across multiple locations;
- sales-order processing;
- warehouse management;
- purchasing;
- customer-specific pricing;
- credit limits;
- backorders;
- partial fulfilment;
- returns;
- trade customers;
- multiple sales channels; and
- order-to-cash reporting.
The exact capabilities vary significantly between ERP products.
Payment functionality may be built into the ERP, supplied through a connector, or provided by an external gateway or payment service provider.
Where do payments fit into the distribution order-to-cash process?
Order-to-cash describes the wider process from a customer placing an order through to the business receiving and settling payment.
For a distributor, that journey might involve several different payment arrangements.
Payment at the point of order
A customer pays by card when the sales order is created.
Deposit followed by balance
The business collects a deposit initially and the remaining amount later, for example when goods are dispatched.
Payment after dispatch
The customer is invoiced once goods have been shipped.
Trade credit
An approved business customer may receive 30-day, 60-day or other agreed payment terms.
Telephone or account-manager payment
A customer may place an order through a sales representative and make payment by card without using an ecommerce checkout.
B2B portal payment
Customers may log into a trade portal to place orders, view outstanding invoices and make payments.
The ERP needs to maintain an accurate record regardless of which payment route is used.
Need payments to work with your distribution ERP?
Tell us which ERP you use, how customers currently pay and what needs to happen between order, payment, settlement and reconciliation.
Merchant Advice Service can use those requirements to help identify gateway and merchant account providers that may fit the existing workflow.
Get personalised recommendations
How can distributors take card payments through ERP workflows?
The payment journey depends on how orders are created.
A distribution business may need to take card payments through:
- B2B ecommerce;
- a trade portal;
- telephone orders;
- sales representatives;
- a warehouse or trade counter;
- payment links;
- invoice-payment pages;
- recurring arrangements; or
- another connected sales channel.
The ERP integration should ideally preserve the relevant order or customer reference throughout the transaction.
For example:
sales order 45872 → payment request → gateway transaction → processor reference → settlement → ERP record updated.
This can make it easier to understand which customer and order produced each payment.
Where does the payment gateway fit?
The payment gateway provides the technical connection used to submit online or other card-not-present transactions for processing.
In a distribution ERP environment, the flow may look broadly like:
ERP or sales channel → payment interface → gateway → acquirer → card network → card issuer.
The response then needs to return to the relevant system.
Depending on the integration, that might include:
- authorisation status;
- transaction reference;
- amount;
- currency;
- capture status;
- refund status;
- token reference;
- settlement information; and
- other data needed for reconciliation.
Businesses can explore payment gateway providers, but the ERP integration requirements should be understood before choosing a gateway.
Authorisation and capture can matter for distributors
Distribution businesses do not always want to take the final card payment at the moment an order is entered.
An order may be:
- subject to stock availability;
- fulfilled from several warehouses;
- partially shipped;
- changed before dispatch;
- split across several deliveries; or
- cancelled before fulfilment.
Some payment setups therefore use separate card authorisation and capture.
A simplified journey might be:
order received → payment authorised → inventory confirmed → goods dispatched → payment captured.
SAP, for example, documents payment-card functionality within sales and billing documents and supports tokenised card processing through its digital-payment integration. :chatgpt-content-reference{index="2"}
Whether separate capture is appropriate depends on the payment provider, card scheme, transaction type and business workflow.
Stored cards and repeat B2B customers
Many distributors have repeat trade customers placing orders regularly.
A suitable payment setup may allow the business to use tokenisation so that repeat customers do not need to provide full card details every time they place an order.
Instead of storing raw card information inside the ERP, the payment provider can return a token or other reference that represents the payment method.
The ERP may then associate that reference with the relevant customer account.
This can support workflows such as:
trade customer places order → approved stored payment method selected → transaction processed → order updated.
The exact use of stored credentials needs to follow the payment provider's technical requirements, card-scheme rules and the customer's agreed payment arrangement.
Card payments and trade credit can exist in the same ERP
A distribution business does not need every customer to pay in the same way.
For example:
- new customers may be required to pay by card;
- established customers may receive credit terms;
- customers approaching their credit limit may need to make a payment before another order is released;
- some invoices may be paid by bank transfer; and
- overdue balances may be collected through a payment link or card transaction.
This makes the customer account inside the ERP important.
Payment status, open invoices, credit limits and order-release rules may all affect whether another order can proceed.
Distribution ERP payments vs accounts receivable automation
This guide focuses on payments within the wider distribution order-to-cash process, including sales orders, fulfilment and customer payments.
Accounts receivable automation is a narrower finance workflow focused more heavily on:
invoice → reminder → collection → payment → settlement → reconciliation.
If your main requirement is automating invoicing, payment chasing and reconciliation, see our ERP & Accounts Receivable Automation guide .
Distribution ERP is one type of integrated payment environment
ERP payment integration sits within the wider category of integrated payments.
Integrated payments connect payment activity with software used elsewhere in the business.
That could include:
- ERP;
- EPOS;
- CRM;
- accounting software;
- booking systems;
- industry-specific software; and
- bespoke applications.
For the broader subject, read our Integrated Payments guide.
This distribution ERP page should be used where the payment problem specifically sits inside wholesale, inventory and order-management workflows.
Managing payments across wholesale, ecommerce and trade counters
Many distributors now sell through more than one channel.
A business might simultaneously operate:
- B2B sales teams;
- trade counters;
- telephone ordering;
- an ecommerce website;
- a customer portal;
- marketplaces; and
- physical retail locations.
Different channels may use different payment methods or even different payment providers.
The ERP can provide the central commercial record, but the payment architecture still needs to establish:
- which merchant account receives each transaction;
- how transaction references are created;
- how refunds are handled;
- how settlement is reported;
- which legal entity owns the sale; and
- how each transaction is reconciled.
Multi-site and multi-entity distributors need a clear merchant-account structure
Larger distributors may operate several warehouses, branches, brands or legal entities.
The payment structure should reflect how those businesses actually trade.
Questions can include:
- Does each legal entity need its own merchant account?
- Do different branches require separate merchant IDs?
- Should settlement go to one bank account or several?
- How should transactions be reported by branch or business unit?
- Can one gateway support several merchant accounts?
- How are currencies handled?
- How does the ERP identify the correct payment route?
The answer depends on the corporate structure, payment provider and ERP architecture.
International distribution adds another payment layer
Businesses selling across borders may need to consider:
- customer currencies;
- settlement currencies;
- merchant location;
- customer geography;
- cross-border card costs;
- local acquiring;
- international merchant accounts;
- multiple legal entities; and
- regional payment methods.
The ERP may be capable of managing multiple currencies, but that does not mean every payment provider can support the same acquiring or settlement model.
International businesses should therefore review the payment architecture alongside the ERP configuration.
For the acquiring side, see our guidance on international merchant accounts and card processing.
Reconciliation is critical in high-volume distribution payments
Distribution businesses can process large numbers of sales orders, invoices, refunds and adjustments.
The payment system therefore needs to provide enough information to trace:
sales order → invoice → transaction → refund or adjustment → settlement → bank receipt.
Reconciliation becomes more complex where:
- one customer pays several invoices together;
- one order is fulfilled in several stages;
- deposits and balances are collected separately;
- refunds occur after settlement;
- fees are deducted from payouts;
- multiple branches or entities are involved; or
- several currencies are used.
Oracle NetSuite's current documentation, for example, describes payment processing as connecting accounts receivable and other processes with external payment systems and financial institutions, including payment handling across multiple organisations, regions and currencies. :chatgpt-content-reference{index="3"}
For the wider reconciliation process, read our Payment Reconciliation guide.
Returns, refunds and credit notes need to stay connected
Distribution businesses regularly deal with:
- returned goods;
- damaged stock;
- short shipments;
- cancelled backorders;
- pricing adjustments;
- credit notes; and
- partial refunds.
A payment refund should not sit separately from the commercial record.
Ideally, the ERP, finance process and payment provider should retain enough common references to identify:
original order → original payment → returned item → credit note → refund → settlement adjustment.
This is particularly important where finance, warehouse and customer-service teams use different parts of the ERP.
Changing gateway or acquirer?
In a distribution environment, switching provider can affect order entry, stored cards, customer accounts, ecommerce, refunds and reconciliation.
Map the complete payment workflow first. Merchant Advice Service can then help identify providers that may fit the existing ERP and acquiring requirements.
Find suitable providers
Changing payment provider when payments are connected to ERP
Once payments are part of the ERP workflow, changing provider can become a technical migration rather than simply opening a new merchant account.
The existing setup may include:
- gateway credentials;
- APIs;
- webhooks;
- stored card tokens;
- payment links;
- merchant IDs;
- terminal integrations;
- custom ERP fields;
- refund processes;
- settlement reports; and
- reconciliation rules.
Before switching, document:
order source → ERP → payment initiation → gateway → acquirer → result → fulfilment → settlement → reconciliation.
Then establish how each stage works with the replacement provider.
A cheaper transaction rate can be poor value if the change creates significant development work or removes automation that finance and operations teams rely on.
What should distributors compare between payment providers?
ERP compatibility
Is there an existing connector, API, middleware option or realistic development route?
Payment channels
Can the provider support ecommerce, telephone orders, B2B portals, trade counters and other channels required by the business?
Authorisation and capture
Can the payment flow support the way orders are fulfilled, including delayed or partial fulfilment where necessary?
Stored payment methods
Can repeat customer payment credentials be tokenised and reused appropriately?
Multiple merchant accounts
Can the gateway work across several branches, legal entities or merchant IDs where required?
International payments
Check currencies, customer countries, settlement currencies and acquiring coverage.
Refunds
Can refunds and partial refunds be linked back to the original ERP transaction?
Settlement
How quickly are funds paid and what settlement-level data is supplied?
Reconciliation
Can payments be matched reliably to orders, invoices and customers?
Overall cost
Compare gateway, processing, integration and operational costs rather than one headline transaction percentage.
How Merchant Advice Service helps with distribution ERP payments
Merchant Advice Service helps businesses understand the payment requirement before comparing merchant account and gateway providers.
For a distributor, wholesaler or other ERP-led business, that can mean looking at:
- ERP platform;
- order-management workflow;
- sales channels;
- current gateway;
- current acquirer;
- monthly card volume;
- average transaction value;
- trade-credit arrangements;
- telephone payments;
- ecommerce;
- stored cards;
- authorisation and capture;
- refunds;
- multiple branches or legal entities;
- international requirements;
- settlement;
- reconciliation;
- API and integration requirements; and
- anything the next provider needs to do differently.
We can then help identify payment providers whose acquiring and technical capabilities may fit those requirements.
Merchant Advice Service does not sell or implement ERP systems and does not develop payment integrations. Technical implementation should be agreed with the relevant ERP vendor, payment provider and development partners.
Find a payment provider that fits your distribution workflow
Tell us how orders are created, how customers pay and how payment information needs to move through your ERP.
Merchant Advice Service can use those requirements to help identify gateway and merchant account providers that may be suitable.
Get personalised recommendations Explore gateway providers
Sources & References
- Microsoft Dynamics 365 – Order-to-Cash Process – current guidance describing the end-to-end order-to-cash process, including sales orders, accounts receivable, credit and collections.
- Microsoft Dynamics 365 – Managing Order to Cash – guidance describing order-to-cash from customer order through payment receipt and settlement.
- SAP S/4HANA – Payments in Sales and Billing Documents – example of ERP payment-card processing, tokenisation and PSP integration within sales workflows.
- Oracle NetSuite – Payment Processing Options – examples of connecting ERP accounts receivable, ecommerce and payment processing across organisations and currencies.
- Merchant Advice Service – Integrated Payments – broader guidance on linking payment acceptance with ERP, CRM, EPOS and other business software.
- Merchant Advice Service – ERP & Accounts Receivable Automation – deeper guidance on invoice collection, AR automation and finance workflows.
- Merchant Advice Service – Payment Reconciliation – guidance on matching payments, fees, settlement and bank receipts.
- Merchant Advice Service – Editorial & Research Policies – information about how MAS researches and reviews payment information.
Editorial & Commercial Disclosure
This guide explains payment-processing considerations for wholesale and distribution ERP environments. References to ERP vendors are included to illustrate current functionality and are not rankings or recommendations.
ERP, gateway and acquiring capabilities vary and can change over time. Businesses should confirm current technical compatibility with their ERP vendor, payment provider and implementation partners before changing payment infrastructure.
Merchant Advice Service is an independent payments information and provider-matching service. MAS does not sell, implement or maintain ERP software or payment integrations.
MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles contained within this guide.
Final provider approval, technical implementation, pricing, settlement and contractual terms remain the responsibility of the relevant payment provider, ERP supplier and other implementation partners.
