Ledger or monthly totals: two honest ways to track sales by hand

If you sell on someone else's platform and do not connect an app to it, every number you track is one you type. That is not a flaw in the method; it is the method. There are two honest ways to do it, and the only real mistake is mixing them up.

Sellers who track by hand describe the same problems. On the Shopify Community forum in September 2025, one seller put it as "Payout ≠ orders: fees, taxes, shipping, and refunds don't line up cleanly." In July 2026, another said of the spreadsheet approach: "It's always a week behind, it's manual." Neither method below takes the typing away. Both make what you type add up.

Method one: the ledger

One row per order: the date, the product, the storefront, what the buyer paid, any refund, and whether the platform charged its advertising fee on that order. Each row works out its own fees from that storefront's rates, and its net is what the buyer paid, minus the fees, minus any refund.

What it tells you: net per product as well as per storefront. Because each row names the product, you can see which products earn and, if you note how long each took to make, what each earned per hour.

What it costs: a few details per order. At a handful of orders a week that is nothing. At forty a week it is a chore, and a chore is what gets skipped.

Method two: monthly totals

One row per storefront per month, typed from the platform's own statement: gross sales, the number of orders, refunds, and the part of gross the platform charged an ad fee on. The same rates apply to the totals:

fees = gross × the percentage fees + orders × the fixed fees per order + ad-attributed gross × the ad fee

A worked month, at Etsy's published US-seller rates (6.5% transaction, 3% + $0.25 processing, $0.20 renewal per sale, 15% Offsite Ads): $412.50 gross from 38 orders, $9.99 refunded, and $59.98 of the gross ad-attributed.

fees = 412.50 × 0.095 + 38 × 0.45 + 59.98 × 0.15 = $65.28

net = 412.50 − 65.28 − 9.99 = $337.23

The order count is not optional. Leave it blank and the $0.45 per order disappears: the same month reads $48.18 in fees, and $17.10 of real cost goes missing.

What it tells you: net per storefront, the effective fee rate, and profit after ads once your ad spend is logged against the same storefront.

What it cannot tell you: anything per product. A statement total does not say which file sold.

The one rule: never both for the same month

If you log July's orders on a storefront one by one and also type that storefront's July statement, July counts twice. Choose per storefront, per month. Mixing is fine across storefronts, a ledger for a new, quiet one and monthly totals for a busy one, as long as each month of each storefront lives in one place only.

Choosing

• You need to know which product earns: the ledger.
• A storefront has too many orders to log one by one: monthly totals for that storefront.
• You are starting on a second storefront: a ledger there, whatever you do on the first.
• A refund: on the ledger, on the order's own row; in monthly totals, the refunds figure from the statement.

Checking it against the payout

Once a month, compare each storefront's net with what it actually paid out. Expect a gap: payouts run on their own schedule and carry lines your rows do not, such as tax. The test is not whether the two match to the cent. It is whether you can name what the difference is.

Both methods are built into Lunith Commerce OS as its Sales and Months databases, adding up on one row per storefront. They work just as well in a spreadsheet, with the rates kept on a tab of their own.