A merchant asks what they made yesterday and expects one number. Square has at least four candidates, they differ by hundreds of dollars on a normal day, and each one is correct for a different question.
The confusion is not carelessness. The terms sound like synonyms. Gross sales, total collected, net sales, and the number in the bank all describe money that moved, and the differences between them are made of tips, tax, refunds, fees, and timing.
The four numbers
Gross sales is what you charged for the work. Services, products, the line items on the ticket. It excludes tips, because a tip is not yours to count as revenue in the same way a service is. It excludes tax, because tax is money you are holding for the state.
Total collected is what the customer actually paid. Gross sales plus tips plus tax. This is the number on the receipt and the number that hit the card.
Net sales is gross sales minus refunds. It answers what you earned after giving some of it back. Note what it does not subtract: processing fees are not in this number.
Net deposited is what reached the bank. It is none of the above, and it is the one merchants actually care about, because it is the only one that pays rent.
Where each one comes from
If you are pulling from Square's Payments API, the mapping is direct. A payment object carries several money fields and they are not interchangeable.
amount_money -> gross sales (before tips, before tax)
tip_money -> tips collected
tax_money -> tax collected
total_money -> total collected (the full charge)
The relationship holds exactly:
total_money = amount_money + tip_money + tax_money
The trap is amount_money. The name suggests it is the amount of the
transaction, and it is not. It is the subtotal. Any integration that reads
amount_money as "the sale" will undercount every ticket that carried a tip,
and in service businesses that is most of them. Any integration that reads
total_money as revenue will overcount by the same amount, and will book tax
as income.
One thing that is not in the customer's charge at all: processing fees. Square
does not add its cut to what the customer pays. It deducts it later, on the
payout side. So total_money is the full charge and still not the money you
keep.
Which number answers which question
"How is the business doing?" Gross sales. It is the cleanest measure of work sold, unaffected by how generous customers were with tips or what the tax rate is. Comparing gross sales month over month tells you something real about demand.
"What did the customer pay?" Total collected. Useful for reconciling a single ticket or a single day against card processor records.
"What did I actually earn?" Net sales, then subtract processing fees. Net sales alone is incomplete for this, since it accounts for refunds but not the percentage the processor takes.
"What can I spend?" None of them. That is net deposited, and it involves payout timing on top of every deduction above.
Why tips deserve their own column
Folding tips into revenue is the most common version of this error and the most distorting.
Tips do not scale with your pricing decisions. They scale with service, staff, and tipping culture. A month where gross sales are flat and tips are up 15 percent is not a month where the business grew. If tips are inside your revenue number, you cannot see that, and worse, you will read a strong tipping period as demand and make pricing or staffing decisions on it.
There is also the pass-through problem. In many businesses tips are owed to staff. Counting money you are going to hand to someone else as revenue makes every margin calculation downstream wrong.
Tax has the same structure and is even less ambiguous. It was never yours.
What this looks like in practice
Analytir stores each component separately rather than deriving them, so any of the four questions above can be answered without recomputing from a single collapsed figure.
COALESCE(SUM(t.gross_amount), 0::numeric) AS gross_sales,
COALESCE(SUM(t.tip_amount), 0::numeric) AS tips_collected,
COALESCE(SUM(t.tax_amount), 0::numeric) AS tax_collected,
COALESCE(SUM(t.refund_amount), 0::numeric) AS refunds,
COALESCE(SUM(t.processing_fee), 0::numeric) AS processing_fees,
COALESCE(SUM(t.total_collected), 0::numeric) AS total_collected,
COALESCE(SUM(t.gross_amount - t.refund_amount), 0::numeric) AS net_sales
The reason to keep them apart is that the gap between what you sold and what you banked is made of these specific pieces. Collapse them into one revenue figure and the gap becomes unexplainable. Keep them separate and every dollar of difference has a name.
A real day from a merchant account, with tax at zero because the category is not taxed in that state:
gross_sales 260.00
tips_collected 52.00
tax_collected 0.00
total_collected 312.00
processing_fees 7.65
net_sales 260.00
Six numbers for one day of work. The business sold $260. The customers paid $312. Square will keep $7.65. None of those is what shows up in the bank, and the reason for that last gap is timing, which is a separate problem.