Where you sell and where you store stock are tax decisions before they are growth decisions
Two American realities shape the build. Selling into a state, or holding inventory there, can create a sales tax obligation, so expansion and fulfillment choices are tax questions before they are growth ones. And returns expectations are set by the largest retailers, so a smaller store is measured against a standard it did not choose.
The United States is not one market for an online store. It is a set of overlapping obligations that switch on according to where your customers are and where your stock sits, and a returns culture that the biggest retailers defined on everyone else's behalf. Neither shows up in a platform demo. Both show up later, usually as an accountant's question nobody can answer from the store's own data.
A store adds a third-party fulfillment provider to shorten delivery times, and the provider splits inventory across warehouses in states the business has never thought about. Holding stock somewhere can create a physical connection to that state. Separately, sales volume into a state can create an obligation without any physical presence at all. Neither event announces itself. The obligation accrues quietly and surfaces during diligence, or when an accountant finally asks where the goods are held. By then the exposure is historic, and the store cannot answer the basic question, what did we sell, into which state, and when, because the order data was never structured to answer it.
When this work makes sense
Questions worth asking any supplier
Does the proposal treat tax calculation as a configuration or as a data question, because the obligation depends on facts about your business that no plugin can know.
Can the store report sales by destination state on demand, because your accountant will need that and rebuilding it later from exports is painful.
Who decides where inventory is held, because if that is your fulfillment provider's choice then a vendor is setting part of your tax footprint.
Does the return flow capture a reason code merchandising will actually use, because otherwise returns are a cost line with no cause attached.
Are refunds designed to return the tax collected, because a refund that quietly keeps it is a problem you will unwind by hand.
Deliverables
Tax calculation integrated at checkout, with product-level treatment set up rather than one blanket rate
Order data structured so sales by destination state, and by marketplace versus direct, can be reported without an export
An inventory location record that makes your physical footprint visible when it changes
Exemption certificate handling where you sell to businesses, so resale orders are not taxed by accident
A returns flow with reason codes, prepaid label generation and a refund path that returns tax correctly
Return reporting by product, variant and reason, so the causes are visible to merchandising
A written handover for your accountant covering what the store collects, records and can report
Built with
Process
Before any design work, we map where you sell, where your stock physically sits and which of your products are treated differently from one another. That map is the input to everything else: it determines what the checkout must calculate, what the order record has to store and what the store must be able to report. We are not accountants and do not advise on whether an obligation exists, that judgment rests with your CPA or tax counsel, and several states set their own tests. What we can do is make sure the answer is available from your systems rather than reconstructed under pressure.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three ways to handle sales tax in the store
Manual rates in the platform
Fits: A single-state seller with a simple catalog and no plans to expand
Limits: Stops being workable the moment you sell into a second state or add a product type treated differently
An automated tax engine at checkout
Fits: Most growing stores, and anyone with mixed product types or several destination states
Limits: Adds cost and a dependency, and it is only as accurate as the product mapping you give it
Marketplace collects, you sell direct as well
Fits: Sellers whose volume runs mostly through marketplaces
Limits: Splits your obligation in two, so your own channel still needs the full setup and your reporting has to separate them
Case studies
No published US ecommerce case study yet, and no client tax outcomes will ever be published. Our New York office is at 1 Liberty Street, 23rd Floor. Client work will be published when we have permission to name the business and can evidence what changed.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Do we have to collect sales tax in every state?
No, and which ones apply depends on where your customers are and where your inventory sits. Several states set volume or activity tests, and they are not identical. We are not tax advisers, so the determination belongs with your CPA. Our job is making sure the store can implement the answer and evidence what it did.
Does using a fulfillment provider change our tax position?
It can, because holding inventory in a state is a form of presence. The risk is that inventory placement is the provider's optimization, not your decision, so the footprint moves without anyone telling you. We build a record of where stock is held and make changes visible, then your adviser decides what follows from it.
Marketplaces collect tax for us. Is that enough?
Not for your own store. Marketplace facilitator rules shift collection to the platform for sales made there, but sales through your own site remain yours to handle, and both may count toward a state's thresholds. The practical requirement is reporting that separates the channels cleanly rather than showing one combined revenue figure.
Do we have to offer free returns?
You have to decide consciously, which is different. The largest retailers set customer expectations and a smaller store is measured against them whether or not that is fair. In some categories free returns are the cost of competing; in others a clear, fast, paid return is accepted. What loses customers is a policy that is hard to find or hard to use.
How do we reduce returns without hurting sales?
By finding out why they happen, which requires reason codes captured at the point of return and read by whoever owns the product page. Most returns cluster on a small set of products and a small set of causes, sizing, a misleading photo, a specification stated ambiguously. Those are fixable. Returns with no reason attached are not.
Should the refund include the sales tax we collected?
Generally yes, and a store that quietly keeps it creates a reconciliation problem plus an unhappy customer. Partial refunds and restocking deductions are where this goes wrong, because the tax portion has to be apportioned rather than ignored. We build the refund path so it is calculated rather than typed, and your accountant confirms the treatment.
Which platform should we use?
That depends on catalog complexity, fulfillment and how much of checkout you need to control, and the honest trade-offs between the platforms are set out on our ecommerce platform pages rather than restated here. What matters for this market is that whichever one you pick must be able to report sales by destination and handle product-level tax treatment.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.