Retail ERP Consultant, USA

Sales tax at the register in every store location

In US retail, the tax on a receipt is decided by where the sale happens and what is being sold. A chain with stores in several states, and sometimes in several cities or counties within one state, has to charge a different combined amount at different registers. Some states also treat categories such as clothing, groceries or prepared food differently from general merchandise, and tax holidays can change the result for a short period.

That puts three requirements on the system. First, every store needs a correct tax location, and every product needs a tax category the POS understands. Second, someone must own updates when jurisdictions change, which is why many retailers connect a specialist tax engine rather than maintain tables by hand. Third, returns must reverse tax correctly, including a purchase made in one state and returned in another.

Buy online, pick up in store adds one more question: is the sale sourced to the store or to the shopper's address? I do not give tax advice. I document each scenario, agree the expected outcome with your tax advisor, and turn those cases into UAT scripts so the platform is tested against them before a single store goes live. The US ERP consultant page covers the wider multi-state tax picture for finance teams.

Loyalty, gift cards and returns across a chain

American shoppers expect their rewards to work in any store and online. When loyalty lives in a separate app, the register often cannot see the balance, points are granted twice on exchanges, and nobody can say what the program costs in margin. I specify where the customer record lives, how points are earned and reversed, and how loyalty discounts are posted so merchandising can measure them.

Gift cards bring a finance angle. A card sold is a liability until it is redeemed, and unredeemed balances may fall under state unclaimed property rules, which your advisor should confirm. The ERP should show outstanding balances by issue date and channel, not just a single total.

Returns are the third piece. Generous return policies are common, so the POS needs rules for receipted and non-receipted returns, refund to original tender, store credit, and returns of online orders at a store counter. Each of those touches stock, tax, loyalty and cash differently. I write them as scenarios with expected postings, then check whether the shortlisted POS handles them natively or needs an add-on. If online orders are a growing share, read ERP for eCommerce alongside this page.

Feeding stores from a DC and keeping shrink visible

Once a US chain opens a distribution center, store replenishment becomes a planning job. New season receipts are allocated across stores by size curve and store grade, then fast sellers are topped up from DC stock based on store sales and minimum display quantities. Freight cost, truck schedules and store receiving capacity all limit what can be sent. I map that cycle from purchase order to store shelf and decide which parts the ERP must automate and which stay with the allocator.

Shrink sits on the other side of the same stock record. Theft, damage, vendor shortages and paperwork errors all look the same if the only signal is a variance at the annual physical inventory. The design I usually recommend combines:

• cycle counts by store and high-risk category on a fixed rhythm;
• reason codes on every stock adjustment;
• confirmation at both ends of every transfer;
• exception reports on voids, no-sale drawer opens and manual price overrides.

For the warehouse side of this design, my Odoo Inventory page for US companies covers DC receiving and 3PL stock, so I do not repeat it here.

Store P&L and leaving QuickBooks plus a standalone POS

Many US retailers grow on QuickBooks with a separate POS that posts a daily summary. It works until owners and lenders ask which stores actually make money. Answering that needs sales, cost of goods, markdowns, shrink, labor and occupancy cost by store, and a summary journal cannot provide it.

The ERP design starts with dimensions: store, district, format and channel on every relevant transaction. Then card processor settlements are matched to POS tenders per store, so deposits reconcile daily rather than at month-end. Payroll usually stays in a dedicated US payroll service, with labor cost brought in by store.

Migration needs care. Item masters in a single-store POS are often duplicated per location, with size and color as separate items. I rebuild the catalog as styles with variants before loading it, and plan opening stock from a fresh count rather than trusting the old system. The QuickBooks migration guide covers the accounting side.

Timing matters too. I plan cutovers away from the holiday trading period and back-to-school, and pilot in one store before a district rollout. Workshops run remotely in hours that suit your main time zone, and any on-site visit is by arrangement.