Pricing and unit economics

The core deliverable is a unit economics model broken out at whichever level matches your business: SKU, product line, subscription plan, or customer segment. For a product business, each unit carries its sale price, cost of goods sold, the payment processing or marketplace fee actually charged on that sale, shipping or delivery cost, and a return and refund allowance built from your own historical return rate rather than an assumed number. For a subscription business, each plan or segment carries monthly recurring revenue, cost to serve (hosting, support, account management time), customer acquisition cost pulled from your actual marketing and sales spend, and a lifetime value estimate driven by your measured churn. Alongside the model itself you get a short written summary in plain language: which lines are strongest, which are weakest, and what is driving the gap, so the numbers translate into a decision without a walkthrough call every time.

We start with a short intake covering your product or plan list, how sales data is currently tracked, and which fees and costs are already itemized versus buried in a general ledger account. From there we pull twelve months of transaction detail where it exists, allocate shared costs (shipping supplies, a shared support team, platform subscription fees) across units using a method we agree with you up front, and build the baseline model. We review the first draft together, since owners often catch a misclassified cost or a fee structure we assumed incorrectly faster than we can find it alone. Once the baseline holds up, we layer in the specific pricing scenario you are weighing, whether that is a flat price increase, a new tier, or absorbing a processor fee change, and show the margin effect under a few volume assumptions rather than one.

This fits a business that has grown past a single product or plan and suspects, correctly or not, that not everything it sells is equally profitable. An ecommerce business selling across its own site and Amazon, where fee structures differ enough to change the real margin picture. A SaaS company with three or four pricing tiers and a hunch that the lowest tier is not covering its support cost. A restaurant group or agency pricing a new service line without a clean read on what it actually costs to deliver. It is less useful for a single-product business with one clean margin number already tracked correctly, since there is no blended average left to unpack.

The most common issue is a shared cost that never gets allocated down to the unit level, so every product looks equally profitable until it is split out and one line turns out to be underwater. The second is marketplace and processing fees buried in a single lump in the chart of accounts rather than tied to the specific channel or order that generated them, which hides real channel-level margin differences. The third is customer acquisition cost calculated once at company formation and never updated, so a SaaS business is still pricing against a CAC figure from two years ago that no longer reflects current ad costs or sales cycle length. The fourth is return and refund cost treated as a rounding error rather than netted against the specific product line generating most of the returns.

Most engagements run on your existing accounting platform: QuickBooks Online, Xero, or NetSuite for the underlying general ledger and transaction detail. For a business selling through Amazon or Shopify, A2X pulls settlement-level detail (fees, refunds, shipping) that reconciles cleanly to the platform payout, which is far more accurate than estimating fees from a percentage assumption. The model itself is built in Excel or Google Sheets so you retain full visibility into every formula and assumption, and so the file keeps working under your own license after the engagement, with no proprietary platform lock-in.

Pricing for unit economics work depends on how many product lines or plans need to be modeled, how much of the underlying transaction data is already clean versus needing reconstruction, and whether this is a one-time analysis or an ongoing quarterly refresh tied into a broader advisory engagement. It is typically scoped as a project fee for the initial build, with a lighter recurring fee if you want it refreshed each quarter. See the pricing page for current advisory ranges; your exact fee is confirmed in writing before work starts.

Every model goes through a senior review before it reaches you, checking that fee assumptions tie back to an actual statement rather than an estimate, that shared cost allocations are documented and defensible, and that the scenario outputs are internally consistent (a lower price at higher assumed volume should not silently produce a higher total margin than the model's own inputs support). We also stress-test the model against a period you already know the outcome for, so you can see it reproduce a result you recognize before trusting it for a forward decision.

Marketplace and payment processor fee structures change more often than most owners track closely, and a model hardcoded to today's fee percentage breaks the first time a platform adjusts its rate card. We build the fee assumptions as inputs you can update yourself, not constants buried inside a formula, specifically so the model keeps being useful after a rate change rather than needing to be rebuilt. The same applies to shipping carrier rate changes and payroll-driven cost-to-serve figures for a subscription business, both of which move at least annually for most companies we work with.