Contact Info
What does a US eCommerce brand need from an ERP?
A US online brand needs an ERP that pulls orders from its own store and every marketplace into one hub, separates marketplace-collected sales tax from tax it must file itself, reconciles payouts net of fees, chargebacks and refunds, and shows contribution margin per order after shipping, 3PL charges and ad spend. I define those requirements, compare platforms and guide delivery remotely, independent of any vendor.
Last reviewed by Vikas Saroj
A typical American direct-to-consumer brand sells through its own storefront, at least one large marketplace and perhaps a social shopping channel, while a 3PL in another state ships most orders. Revenue looks healthy in the storefront dashboard, yet the bank deposits never quite match it, and nobody can say which orders actually made money.
As an independent consultant working remotely with American sellers, I trace each channel from checkout to deposit, document how tax, fees, refunds and fulfillment costs land in the books, and then specify what the ERP and its connectors must do before you sign with any vendor or implementer.
The goal is a back office where finance, operations and marketing read the same order and the same margin.
I define how orders from your storefront, marketplaces, social channels and wholesale portal enter one hub, which system owns order status, and how cancellations and edits flow back to each channel.
Marketplace orders where the platform collects tax, own-store orders where you do, and exempt wholesale orders are tagged separately, so returns are prepared from clean data that your CPA can review.
Marketplace settlement reports and card processor payouts are broken into sales, fees, refunds, chargebacks, reserves and adjustments, posted through clearing accounts and matched to the deposit that reaches your bank.
Pick fees, storage, packaging and label charges from 3PL invoices are mapped to orders or channels, so fulfillment cost per order comes from data instead of a monthly estimate.
I specify a margin view per order, SKU and channel that subtracts product cost, discounts, shipping, payment fees, returns and allocated ad spend from Google, Meta and marketplace advertising.
I score ERP options and connector stacks against your real order scenarios, review implementation proposals, then support UAT on orders, refunds and payouts before the switch.
An ERP for ecommerce should make these numbers available without a spreadsheet. I design the data model and reports around them from the start.
Channels, payouts and costs
Order hub and margin rules
Prove it on real payouts
Most US brands I speak with did not design their stack. A storefront came first, then a marketplace account, then a 3PL, a returns app, a subscription tool and a wholesale portal, each with its own order record. The result is a business where an order can be shipped by the 3PL, refunded in the storefront and still sit open in accounting.
The first requirement is a single order hub. Every order, whatever its source, gets one record that carries the channel, the customer, the items, the tax treatment, the fulfillment location and the payment method. The hub might be the ERP itself or an order management layer feeding it, but the rule is the same: one place decides order status, and the other systems follow it.
Getting there means answering questions that are easy to skip:
I write these as scenarios in the requirements document and use them later as test scripts for ERP integration work, so connectors are proven on awkward orders, not just tidy ones.
Sales tax is where US eCommerce data most often goes wrong. Many states now treat large marketplaces as marketplace facilitators that collect and remit sales tax on the orders placed through them. Sales on your own storefront are different: where you have nexus, whether physical or economic, the obligation to collect and file usually stays with you. Holding stock in a 3PL or marketplace warehouse in another state can also affect where you have obligations.
I do not give tax advice, and the rules vary by state, so the details belong with your CPA or tax provider. What I design is the data underneath. Each order line in the ERP should show who collected the tax, at what rate and for which jurisdiction, so the marketplace-collected amount is not booked as your liability and your own-store tax is not missed.
In practice that means:
Some states still ask sellers to report marketplace sales on their returns even when the marketplace paid the tax, which is another reason to keep both streams visible. My US ERP consultant page covers multi-state tax design for the wider business.
A marketplace does not pay you for orders. It pays you a net figure after commissions, fulfillment fees, storage charges, advertising, refunds, reimbursements and reserve holds, on its own schedule. Card processors and wallets work the same way on a smaller scale, netting processing fees, refunds and disputes from each payout. If the ERP books the gross order as revenue and the bank shows the net deposit, the difference piles up in a suspense account that someone eventually has to explain.
I design reconciliation around clearing accounts. Each marketplace and each payment provider gets its own clearing account. Orders post gross sales and tax into it, the settlement or payout report posts fees, refunds and adjustments, and the bank deposit clears it. Whatever remains is a genuine exception: a missing order, a reimbursement for lost stock, a chargeback lost or won.
Chargebacks deserve their own workflow. Disputed card payments are pulled back from payouts, sometimes with a fee, and may be reversed weeks later. I specify how a dispute is recorded against the original order, who gathers evidence, and how the final outcome posts, so finance can see dispute losses by channel rather than finding them buried in fees.
Before go-live, I run at least one full payout cycle in parallel and reconcile it line by line. If the new setup cannot explain a real deposit, it is not ready.
Revenue per order is easy to report. Profit per order is not, because the costs that decide it live in different systems: product cost in the ERP, shipping labels in a carrier account, pick and storage fees on a 3PL invoice, payment fees in a processor report, returns in a returns app and ad spend in Google, Meta and marketplace advertising consoles.
I define contribution margin as a layered calculation that finance and marketing agree on before any dashboard is built:
The ERP holds the first four layers at order level. Ad spend usually arrives at campaign or day level, so the allocation rule must be explicit: by channel, by first-order customers or by attributed orders. Each option tells a different story, and I document the one you choose.
This is where my paid marketing work connects to the ERP. When margin by SKU and channel is reliable, bidding can favor products that actually earn money after free shipping and returns, rather than those with the best headline return on ad spend.
US shoppers expect easy returns, and generous return windows turn refunds into a real cost line. The ERP needs to record why each item came back, whether it was restocked, refurbished, liquidated or written off, and whether the refund was full, partial or store credit. Store credit and gift cards are liabilities until redeemed, so they need their own accounts rather than being netted against sales.
Customer data needs care too. Several states have consumer privacy laws that give shoppers rights over their personal information, and FTC rules apply to how online sellers advertise and handle orders. Your counsel defines the obligations; I make sure the design limits who sees customer data, keeps marketing consent with the customer record and avoids copying personal data into spreadsheets.
Many brands at this stage run QuickBooks with a set of storefront apps and summary connectors. Migration covers item and bundle masters, open orders, customer balances, gift card liabilities, unsettled marketplace balances and stock at every 3PL and marketplace warehouse, counted close to cutover. I avoid going live in the fourth-quarter peak.
Workshops run remotely in US business hours. The USA hub, my Zoho Inventory page for US sellers and the eCommerce industry page cover related ground.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
Yes. Marketplace-collected tax should be visible but not booked as your liability, and some states still expect marketplace sales on your returns. Keeping a flag on each order line for who collected the tax lets your CPA prepare filings from clean data and prevents double counting with your own-store sales.
Because the deposit is net of commissions, fulfillment and storage fees, ad charges, refunds, reimbursements and reserve holds. I set up a clearing account per marketplace so gross sales and each deduction post separately and the deposit clears the balance. Anything left over is a real exception to investigate.
Product, fulfillment, payment and return costs can sit at order level in the ERP. Ad spend usually arrives by campaign and day, so it needs an agreed allocation rule. I document that rule with finance and marketing, then specify reporting that combines both sources consistently.
Yes, if each site is its own location with its own stock and cost data. The harder part is the integrations: order release, shipment confirmations, receiving and invoice data from each 3PL. I specify each feed and test it with real exceptions before cutover.
I do. Everything is delivered remotely, with live sessions booked inside your working day, whether the core team sits on Eastern, Central, Mountain or Pacific time. Recorded walkthroughs let warehouse and 3PL contacts review designs when it suits them, without extra meetings.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.