Skip to main content
2,200+ service businesses benchmarked. Do you know your gross profit per labor hour? See where you stand →
Level

Software collection playbook

Shopify: separate orders, payouts and Balance

Orders, settlements and bank-like Balance custody.

By Sam Yang · Updated

Are you measuring sales, payout cash or Balance movement?

Choose the source from the question. Sales analysis needs its report definition and return treatment; bank cash needs payout and transfer evidence. Store orders alone do not supply the fee and net-payout bridge.

Evidence basis: Saved store/report collection observations. Report availability and scopes must be checked for the current store.

Prefer adequate orders and payout APIs, correct scopes and store identity. Rate throttling gets queue/backoff/cache handling before browser fallback.

The owner wants a sales-period comparison

Read back the report title and applied date range; export the complete Items shown population and preserve adjustments.

The owner wants to explain a bank deposit

Use Payments payout detail and the actual bank occurrence. Collect Balance transactions and statements separately when those movements are involved.

Use supported API or native report access for the required scope. A permitted browser session can collect a specific gap. Neither route proves reconciliation or complete costs.

Put the evidence to work

Why can Shopify sales rise while the bank deposit falls?

The sales report and the payout explain different events. Refunds, processing fees, adjustments and unsettled activity can change deposit cash without changing the order population in the same way. Start with the payout identity and its underlying transactions, then connect the bank occurrence. Keep Shopify Balance movements separate from Payments activity.

Explain one deposit without mistaking it for sales
  1. Identify the store, payment provider, currency, payout ID and actual receiving account. A Shopify order paid through another gateway belongs to that gateway settlement bridge.
  2. Collect the complete transaction population for the selected payout, preserving transaction dates, payout dates, gross amount, fee and net. Read back applied filters before export.
  3. Reproduce the signed charges, refunds and adjustments less fees. Preserve reserves or pending activity when they explain a difference.
  4. Bind the payout transfer reference, where available, to the actual bank occurrence. A provider Deposited label is not bank evidence.

Bring to the review: A payout bridge with separate sales, refund, fee, adjustment and bank-occurrence columns.

Then decide: Resolve any remaining payout-to-bank exception before deciding whether money is missing.

Explain a sales-report disagreement
  1. Retain the report title, store, date range, timezone and sales definition from both reports.
  2. Keep order date, refund date and payout date in separate fields; do not make them share one monthly filter.
  3. Use complete native order and refund evidence. In a line-item CSV, repeated order rows are not additional orders; count the order identity once.
  4. Compare the same population to the marketing dashboard, including tax, shipping, discounts and refunded sales.

Bring to the review: A definition-and-timing bridge rather than a forced equal total.

Then decide: Use order evidence for the sales question, attribution for campaign response and payout evidence for cash.

Which collection route answers this question?

Choose the route for the missing evidence and the access available in your account. The comparison below distinguishes documented coverage from coverage that still needs checking.

Supported API

What it supplies
The documented GraphQL ShopifyPaymentsBalanceTransaction object exposes balance-transaction structure. Collection must use a supported query, pagination and the account's actual authorization.
What still needs proof
Order access alone does not establish Payments access or Shopify Balance coverage. Required scopes and complete historical access must be checked for the current app and API version.

Choose it when: Repeatable transaction extraction when approved access supplies the required settlement identities.

Native export

What it supplies
Shopify documents payout-transaction CSV exports and separate order exports. Order transaction history contains captured-payment data; it is not a complete authorization history.
What still needs proof
An orders CSV is not the payout fee/net population. Export delivery and range can differ by export choice.

Choose it when: One deposit investigation or a reproducible native report population.

Permitted browser

What it supplies
Saved collection observations support reading report filters and collecting the authorized native report or payout export when that exact source is not supplied by existing access.
What still needs proof
Confirm the current account view and export choice. A visible partial table, export click or emailed-file request is not a completed file.

Choose it when: Verify report definitions, current filters and original file delivery, with no payment or settings change.

Reproduce the diagnostic

Two fictional orders, one later payout

All records and amounts below are fictional teaching inputs. This example demonstrates the calculation, not a customer outcome or a reproduced software defect.

Charges of 120 + 80 = 200. Signed activity is 200 - 20 = 180. Fees are 7. Payout net is 180 - 7 = 173. This fixture deliberately excludes taxes, shipping, reserves and other gateways.

What the CSV columns mean
  • id: fictional transaction identity
  • kind: charge or refund
  • amount: signed USD before processor fee
  • fee: positive USD charged by the processor
  • net: signed USD amount minus fee
  • payout_id: teaching payout identity
Captured charges
200 USD
Charge rows only, before this fixture's refund and fees.
Signed activity
180 USD
Charges less the linked refund.
Processor fees
7 USD
Fees retained as a separate cost.
Payout net
173 USD
Expected payout amount, still requiring the bank occurrence.
Inspect shopify-payout.csv
id,kind,amount,fee,net,payout_id
charge_A,charge,120,4,116,payout_demo
charge_B,charge,80,3,77,payout_demo
refund_A,refund,-20,0,-20,payout_demo
Download this CSV

Next decision: Find the actual bank occurrence for payout_demo; do not book 173 as gross sales.

Run the example locally

Save the CSV files, expected-results.json and reproduce.mjs in one folder. With Node.js installed, run the command below. It calculates the checks from the CSV bytes and rejects a changed input or expected result.

node reproduce.mjs expected-results.json

No software login, customer records or API key is required.

When the result does not make sense

Sales and payout totals disagree

Check: Check provider, event dates, refunds, fees, reserves and pending activity before comparing totals.

Resolve the question: Produce separate sales and settlement bridges; carry unsettled items forward rather than posting a revenue plug.

Order count doubles after CSV import

Check: Inspect repeated order IDs caused by multiple line items.

Resolve the question: Group by unique order identity for order counts; retain line identities for units and item revenue.

Export seems complete but fee detail is missing

Check: Check whether the file is order transaction history rather than payout transactions.

Resolve the question: Collect the payout transaction export for the same identified payout and preserve both originals.

Where automation earns its place

Good work for automation

  • Collect complete paginated records, preserve native identities and reproduce signed payout arithmetic on a stable schema.

Keep a person on these decisions

  • Resolve revenue recognition, gateway coverage, disputed adjustments and ambiguous bank occurrences before changing the books.

References behind these workflows

Product documentation supports the specific scope stated beside each source. Level's diagnostic methods and fictional calculations remain distinct from vendor capabilities.

Explore the financial diagnostic examples

Collect and verify the population

Analytics and order population
Verify store, report definition and applied dates after input; a date field can revert while looking populated.
Payment and payout detail
Preserve fees, adjustments and settlement identities instead of treating net payout as gross sales.
Balance CSV and monthly statement
Treat transfers as movements between sources, not new revenue; do not assume an orders payment CSV contains these fields.

Verify current store and native report title; select dates and read back the applied range. Use complete native analytics export where available, retaining totals/population. For source activity without export, capture the rendered report including values visible on screen that the page extractor may miss. Keep emailed transaction exports pending until received. Collect Balance Transactions CSV and monthly statements separately. Request an emailed export only when the collection authorization explicitly allows it; otherwise leave it pending for the account owner to obtain.

Evidence acceptance checklist

  1. Read back the applied report range and selected store after filter changes.
  2. Keep order activity, Shopify Payments payouts and Balance transactions separate.
  3. Treat emailed exports as pending until the authorized file is actually received.

Fictional collection example

A fictional store has orders in one period and the corresponding payout in the next. Its Balance account also receives a transfer. Return all three source populations separately. Neither the payout nor the Balance transfer is a substitute for gross sales or proof of revenue recognition.

Invented teaching scenario, not a customer result or a reproduced vendor defect.

Capture the setup with the evidence

  • Company, legal entity or account, report name, period, basis, currency and timezone.
  • Selected filters, status, page count, original record identifiers and control totals.
  • Collection time, source route and authorized role. Record browser and automation versions when using a browser.
  • Original files and exceptions. Keep credentials, customer identifiers and financial artifacts private.

A browser version helps reproduce an interface issue. It does not validate the financial conclusion.

Pitfalls and stop conditions

Default Items shown can yield partial CSV; an incomplete page extraction can omit visible report values; date input can revert or shift. Orders payment CSV lacks payout/fee/net detail. Net payout is not sales; Balance transfer is not revenue.

How a plausible answer can go wrong

A complete orders payment CSV can still lack payout, fee and net details. A partial Items shown export or omitted visible report values can also make two apparently identical reports disagree.

Stop if account identity, permission, cutoff or population is uncertain. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.

Read-only AI collection prompt

Replace the bracketed scope before use. This prompt collects evidence; it does not permit edits, approvals or accounting execution. Requesting an emailed report is a separate account action and requires explicit authorization.

Collect read-only evidence for Shopify, Payments and Balance to answer [financial question]. Confirm [company], [account/entity], [period], [basis], [currency] and [allowed reports]. Verify current store and native report title; select dates and read back the applied range. Use complete native analytics export where available, retaining totals/population. For source activity without export, capture the rendered report including visible values inside open-shadow content when the page extractor misses them. Keep emailed transaction exports pending until received. Collect Balance Transactions CSV and monthly statements separately. Retain original files, complete record IDs, counts, filters, collection timestamp and exceptions. Default Items shown can yield partial CSV; an incomplete page extraction can omit visible report values; date input can revert or shift. Orders payment CSV lacks payout/fee/net detail. Net payout is not sales; Balance transfer is not revenue. Stop if the source or scope is uncertain. Do not post, match, reconnect, delete or change settings. Return the evidence for financial review; do not claim the books are correct. Request an emailed export only when the collection authorization explicitly allows it; otherwise leave it pending for the account owner to obtain. Do not approve, submit payroll, pay, transfer, refund, send messages, invite users or accept terms. Stop at any login, MFA or credential prompt and hand back to the account owner. Store files only in [approved private location]. Do not paste customer artifacts into public tools. Use only preauthorized collection actions. Request an emailed report only when its delivery is explicitly authorized; otherwise ask the account owner to supply the file.

Next decision

What does the evidence support?

Hand the owner separate sales and cash explanations with the connecting adjustments named. If report coverage or settlement identity is missing, keep that part of the bridge unresolved.

Compare the same population, identities and cutoff. Keep unsupported costs or settlements visible before using the result for pricing, cash or close.

Open the financial acceptance guide →

Sources and scope

Base product-reference scopes were reviewed . No end-to-end dated native UI walkthrough is published for this software. Individual source rechecks are dated with their citations. Operator decision guidance was reviewed 2026-10-07. The references below support their stated product scope, not every observed interface detail. It is not a vendor capability certification, a measured customer result or an independently reconciled account. Verify current features and entitlement in the account you use.

Content revision history