Financial Preferences

Financial Preferences are five settings that control how MerchantFlow calculates and presents your profit. They cover how sales tax affects your bottom line, when refunded-order costs are counted, whether missing fulfillment costs are estimated, whether fulfillment rates vary by destination country, and how warranty replacement orders are detected. Because these settings change the profit numbers shown across the entire dashboard, it is worth understanding each one before you change it.

How to Access Financial Preferences

1. Click your profile icon in the dashboard header and select Settings, or navigate directly to /dashboard/settings
2. On the General tab, scroll to the Financial Preferences section

Each of the five cards saves independently with its own save button - there is no shared "Save all" for this section.

Quick Reference

Sales Tax Treatment

Sales Tax Treatment decides whether the sales tax you collect on orders is deducted from your profit.

The two options are:

• No - pass-through (default) - Tax is collected from customers and remitted to the government, so it never hits your bottom line. MerchantFlow still shows the estimated tax line in the P&L breakdown, but it does not reduce net profit.
• Yes - deduct from profit - Collected tax is subtracted from your profit. Choose this if you absorb tax in your pricing (tax-inclusive pricing, GST/VAT markets where tax effectively comes out of your margin).

Which option should I choose?

• If your prices are tax-exclusive and you simply pass collected tax on to the tax authority, keep the default No - pass-through. This is the correct treatment for most US-style sales tax setups.
• If your prices are tax-inclusive (common with GST/VAT in Australia, the EU, and the UK) and the tax portion effectively comes out of your revenue, choose Yes - deduct from profit so net profit reflects what you actually keep.

What happens when you change it

Saving a change to Sales Tax Treatment triggers a full-history recompute of order margins in the background. Historical profit figures across the dashboard update to reflect the new treatment - this can take a few minutes on stores with long order histories. The setting flows through every profit surface: dashboard KPIs, P&L pages, North Star history, the Orders page, and the Daily AI Email Summary, so the same number is shown everywhere.

The estimated tax amount itself comes from your per-country Tax Rules, configured at Settings > Tax. Sales Tax Treatment also appears on that tab - it is the same setting in both places, not two separate toggles.

Refund Cost Recognition

Refund Cost Recognition chooses when a refunded order's costs (COGS, payment fees, fulfillment) count against your profit.

The two options are:

• On the sale date (default, recommended) - A refunded order's costs are matched to the day the order was placed, so they line up with the revenue from that order. Revenue and cost for the same order always appear on the same day.
• On the refund date - A refunded order's costs are counted on the day the refund was issued. Cost shows up later than the revenue it relates to, which some accounting approaches prefer because it mirrors when the cash event happened.

What happens when you change it

Nothing recalculates. MerchantFlow pre-computes P&L under both bases, so this setting only changes how stored figures are read - switching is instant and you can toggle it back and forth freely without waiting for any background job. See COGS Accuracy for how this interacts with refund handling in the P&L.

Fulfilment Cost Estimation

Carriers and 3PLs can take a few days to report fulfillment cost back to MerchantFlow. Until those costs arrive, recent orders look more profitable than they really are. Fulfilment Cost Estimation fills that reporting gap on the dashboard.

The two options are:

• Off - show only carrier-reported cost (default) - Profit reflects only confirmed fulfillment data. Recent days may look temporarily overstated until carrier costs arrive.
• On - estimate the last 7 days - The dashboard estimates the missing cost for orders placed in the last 7 days, so profit drops to a more realistic figure for recent orders.

How the estimate works

When enabled, MerchantFlow estimates missing fulfillment cost using your store's historical average cost per order, computed from carrier-reported costs. If there is not enough history yet (at least 5 orders with carrier-reported fulfillment cost), it falls back to your configured fulfillment percentage from the fulfillment cost setup. Orders older than 7 days without fulfillment data are left as-is.

Every dashboard tile that includes an estimate is marked, so you can always tell at a glance which figures contain estimated fulfillment (an amber "Includes estimated fulfilment" indicator).

What happens when you change it

This is a display-time overlay only. Stored P&L data stays raw and unmodified - turning the setting off immediately returns the dashboard to carrier-reported costs only.

Prerequisite: If you turn this on but your store has no fulfillment cost method configured, the setting has no effect yet. You need either 5+ orders with carrier-reported fulfillment cost, or a fulfillment percentage configured on the Integrations page. The settings card shows a warning when this applies.

A related but separate toggle exists for the Daily AI Email Summary: the Profit Accuracy option in Settings > Notifications controls fulfillment estimation in the email independently of this dashboard setting.

Country Fulfilment Rates

Country fulfilment rates let you set different fulfillment costs per destination country - and per quantity tier - instead of one flat per-product rate. Shipping a unit to Australia rarely costs the same as shipping it domestically; this setting lets your P&L reflect that.

The two options are:

• Off - one rate for all destinations (default) - Every order uses your flat per-product fulfillment rate.
• On - set rates per country - Per-country overrides configured on the COGS page supersede your default rate. Orders shipping to a covered country use its rate; orders to any other country use your default per-product rate.

When this card is visible

The Country fulfilment rates card only appears when both conditions are met:

1. Your fulfillment cost method is set to per-product rates, and
2. You do not have a supported 3PL connected

If a 3PL is connected, carrier-reported costs take priority and per-country overrides would never apply, so the card is hidden. See Country Fulfillment Rates for the full setup guide, including quantity tiers.

What happens when you change it

Toggling this setting recomputes historical profit. MerchantFlow queues a background job that reapplies fulfillment costs across your full order history using the new rate structure. Expect historical profit figures to shift once the job completes.

Warranty Order Detection

Warranty replacements are usually zero-revenue orders that still cost you money in 3PL fulfillment. Warranty Order Detection tells MerchantFlow how to spot them, so it can total what warranty fulfillment is costing you across the Orders page, Expenses, your profit breakdown, and the Daily AI Email Summary.

Three detection signals are available, and any combination can be active at once - an order counts as a warranty order if any enabled signal matches:

If all three signals are off or empty, warranty tracking is disabled entirely and the settings card shows a hint to that effect.

What warranty detection changes

Detected warranty orders are categorized, not excluded - their fulfillment costs still count against profit, but MerchantFlow separates them out so you can see the total cost of warranty replacements:

• The Orders page gains a Warranty filter
• The Expenses page shows a warranty fulfilment cost card
• The profit breakdown and daily summary attribute warranty fulfillment separately

Warranty orders correctly show zero revenue and zero COGS impact where the line items are free - the cost that surfaces is the real fulfillment spend.

What happens when you change it

Detection is applied at read time - no recalculation runs. Changing signals immediately changes which orders are classified as warranty across all surfaces.

Best Practices

1. Set Sales Tax Treatment once, early. It is the one setting here that triggers a full-history recompute, and flipping it back and forth makes period-over-period comparisons confusing while jobs run.
2. Keep Refund Cost Recognition on the sale date unless your accountant specifically wants refund-date recognition. Sale-date matching keeps revenue and costs for the same order on the same day, which makes daily P&L much easier to read.
3. Turn on Fulfilment Cost Estimation if you use a 3PL with reporting lag. Without it, the last few days always look more profitable than they are.
4. Give warranty SKUs a consistent prefix (e.g. WARRANTY-) in your store, then set the SKU prefix signal. It is the most precise of the three signals and avoids catching gift cards the way zero-revenue detection can.

Troubleshooting

Profit changed after I saved Sales Tax Treatment

Expected. The setting applies to your full order history, and a background recompute updates historical figures. Give it a few minutes on large stores; the dashboard reflects the new treatment once the job completes.

The Country fulfilment rates card is missing

The card only appears when your fulfillment method is per-product and no 3PL is connected. Check Settings > Integrations for the method and whether a 3PL is linked. With a 3PL connected, carrier-reported costs are used by design and per-country overrides would have no effect.

The estimated fulfilment indicator never appears

Fulfilment Cost Estimation needs either 5+ orders with carrier-reported fulfillment cost (to compute your historical average) or a configured fulfillment percentage. Check Settings > Integrations for your fulfillment method, and see Fulfillment Costs for setup details.

Warranty orders are not being detected

Check that at least one signal is active: zero-revenue detection on, a SKU prefix set, or products selected. The SKU prefix is case-sensitive - warranty- will not match WARRANTY-123. If you rely on the product picker, remember that selecting a product covers all its variants, but a variant selection covers only that variant.

Frequently Asked Questions

Does changing Refund Cost Recognition recalculate anything?

No. MerchantFlow stores P&L under both recognition bases, so the setting only changes which stored figures are read. Switching is instant and fully reversible.

Why is Sales Tax Treatment on both the General tab and the Tax tab?

Convenience. It is a single setting - changing it in either place changes it everywhere. The Tax tab also holds your per-country tax rules, which determine the estimated tax amounts the treatment applies to.

Does Fulfilment Cost Estimation change my stored P&L data?

No. It is a display-time overlay on the dashboard for orders in the last 7 days. Stored figures stay raw, and every tile that includes an estimate is labeled.

Do warranty orders still reduce my profit?

Yes. Warranty detection categorizes their fulfillment cost separately so you can see what warranties cost you - it does not remove that cost from profit.

Can agencies see these settings for client workspaces?

Financial Preferences live on each merchant workspace's own Settings page. Agency users manage them per client workspace, not from the agency portfolio view.

Related Guides

• General Settings - the rest of the Settings > General page (profile, currency, timezone, language, security)
• Tax Rules - per-country tax rates that feed the Sales Tax Treatment setting
• Fulfillment Costs - fulfillment cost methods, percentage setup, and estimation details
• Country Fulfillment Rates - full setup guide for per-country rates and quantity tiers
• COGS Accuracy - how refunds and cost recognition interact with the P&L
• P&L Overview - how the profit waterfall is built

---

Last updated: July 31, 2026