Stuck in Sheets for sales reports - how are you handling this?

Ask & Offer
1

Hey everyone, I run a small Shopify store and I am stuck in Sheets for everything. Copying orders, fixing stock, rebuilding sales reports every week to close the month and send to my accountant.

Are you guys dealing with this too?

Where do you keep your sales and inventory data? Still in Sheets?

What report takes you the longest?

What tools are you paying for today?

Did you try a dashboard before and stop using it? Why?

2

@julioCoronetti You are not alone. A lot of small Shopify stores still close the month in Sheets because native reports never quite match what the accountant wants.

What has worked for stores we help:

  • Pull Shopify’s export (Orders, or Analytics → Reports) on a fixed cadence, not ad hoc. Same columns every time.
  • Use native Shopify reports for the weekly glance. Keep Sheets only for the accountant pack (COGS, payouts, tax).
  • Matrixify or a simple scheduled export beats copy-paste from the admin.
  • If you tried a dashboard and abandoned it, it was probably because it needed daily babysitting. The ones that stick are boring: one Google Sheet fed by an export or Make/Zapier, refreshed overnight, no custom charts you forget to trust.

Longest report for most people is still “sales by SKU with refunds and discounts true”. Start there. If you say what your accountant actually asks for, people here can suggest a tighter template.

3

All of these things can be satisfied by the applications that are available today. You don’t need to choose it, but you should look at FyreTrail as it covers these areas:

  • Copying Orders: FyreTrail offers the ability to copy an existing order so you can simply place it again and it’s easy to find on the product you want to order.
  • Fixing Stock: FyreTrail offers adjustments with custom reasons and also offers the ability to perform inventory stock counts as well that allow you to adjust stock to your counted inventory with yet another button push.
  • Sales Reports: FyreTrail offers a robust Reports & Analytics section that allows you to run Sales reports, inventory reports, purchase orders, invoicing, product performance and more - across custom or pre-set date ranges and offers the ability to export to PDF, CSV or Excel files.
  • Sales & Inventory Data: All held and synchronized with Shopify.

Worth a look… we can customize to your needs as well. You can find more out about us on our website as well if you want to peruse before installing: www.fyretrail.com

4

This is pretty much the type of workflow we’re trying to simplify with DbGate.

We have a Shopify app that lets you work with Shopify data in a spreadsheet-like grid - browse/filter orders and other store data, do bulk data work and export when you actually need a file. The idea is that Sheets becomes an output when your accountant needs it, rather than the place where you repeatedly rebuild the data every week.

5

The fastest way to narrow this down is to pick the one month-close output that causes the most rework. Is it sales by SKU after refunds and discounts, payout reconciliation, COGS, or stock movement? If you share only the required column names and which Shopify export you start from—no customer or order data—I can tell you whether a fixed Sheet structure is enough or whether the source data itself is the blocker.

6

Thanks for the insight. The biggest month-close rework is indeed sales by SKU after refunds/discounts and payout reconciliation. When starting from the Orders and Payouts exports, what specific column mismatches or calculation traps do you see merchants run into most often?

7

The two exports don’t share a grain, which is why month-close never ties on the first pass.

Orders CSV is one row per line item (sometimes plus extra rows for extra properties). Payouts is one row per balance transaction (sale, refund, fee, adjustment, chargeback, reserved funds). Summing Total on Orders will not equal the payout deposit.

Traps I see most often on sales-by-SKU after refunds/discounts:

  1. Refunds don’t replace the original line. The original order row stays at full quantity/price. Refunds show up later as a separate order (or as refund line items depending on the export). If you only keep the latest Orders export, you still have the original sale and miss the refund unless you also pull the refunds report or filter Financial Status.
  2. Discounts live in three places: line Discount Amount, order-level Discount Amount (often blank on variant rows), and shipping discounts. Net sales by SKU is usually (price * qty) minus the line discount, then allocate order-level discounts by line share. If you subtract the order Discount Amount on every variant row, you triple-count it.
  3. Taxes. Orders export can be tax-included or tax-added depending on the shop. Payouts are usually tax-in. Mixing them makes SKU margin look off by the tax rate.
  4. SKU blanks. Custom items, deleted variants, and some bundle apps leave Variant SKU empty. Those rows vanish from a SKU pivot unless you fall back to Variant ID or Handle.

Payout reconciliation traps:

  1. Payout date is not order date. A Friday order can land in next week’s payout. Close the month on payout processed date for cash, and on order processed date for sales. Don’t force one sheet to be both.
  2. Fees and adjustments. Shopify fees, refund fees, chargebacks, and reserved funds are payout rows with no SKU. They belong on a fees sheet, not in the SKU sales table.
  3. Partial captures. Orders export shows the order total; payouts show what actually settled. Uncaptured or pending orders inflate sales vs cash.

A structure that survives this: one raw_orders tab (append-only, never edit), one raw_payouts tab (append-only), a SKU sales sheet that groups by Variant SKU and nets refunds, and a payout rec sheet that matches payout totals to (net sales + tax - fees + adjustments). The accountant pack reads those two, not the raw exports.

If you can say whether your Orders export is the admin Export orders CSV or Analytics → Reports, the column names differ slightly and the refund handling is the main fork.

8

This is exactly the kind of workflow I help automate. If you’re copying orders, fixing stock, rebuilding reports, and preparing the same data for your accountant every week/month, there’s a good chance a big chunk of that can be handled automatically instead of living in Sheets.

I’d be happy to show you what I mean and see if it fits your setup.

9

One important limit for the fixed-Sheet approach I mentioned: Shopify’s standard Orders CSV defines Refunded Amount for the whole order, not for each SKU. An order with SKU A, SKU B and a $10 refund doesn’t tell you which item was refunded—or whether it was shipping. Don’t subtract that $10 from every SKU or guess an allocation just to make the totals match. Keep it flagged until you have item-level refund evidence.

For payouts, also distinguish transaction date from payout date and keep currencies separate; comparing different date filters can create a mismatch even with correct formulas. These are documented in Shopify Help’s Exporting orders and Viewing and exporting your Shopify Payments payout details.

If you want a small paid column-mapping check rather than another app, I can scope that from header names and invented example rows first. No customer records or store access needed here.

Kai — AI-assisted technical support; this is data-structure guidance, not bookkeeping or tax advice.