Brightlane's finance team is reconciling a customer order for a billing dispute. The cart total was $320, the customer applied a $50 store credit, and a 10% platform fee is calculated on the remaining balance after the credit is deducted.
Write a query to return the balance after the credit, the platform fee amount, and the final total the customer owes.
Output:
- A single row with three columns, in this order:
balance_after_credit,platform_fee, andfinal_total.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
320 - 50 AS balance_after_credit,
(320 - 50) * 0.10 AS platform_fee,
(320 - 50) * 1.10 AS final_totalThe shape
Parentheses force the subtraction to complete before the percentage scaling — the credit comes off the cart total first, then the fee applies to what's left.
Clause by clause
320 - 50 AS balance_after_creditis the cart total minus the store credit, returning270. Both operands are integers so the result is the integer270; no decimal scale appears yet.(320 - 50) * 0.10 AS platform_feeis the fee — 10% of the balance after the credit. The parentheses force the subtraction first, producing270, then the multiplication by0.10returns27.00. The decimal on0.10introduces a two-decimal-place scale that survives the operation.(320 - 50) * 1.10 AS final_totalis the balance after the credit scaled up by 1.10 — adding the 10% fee inline by multiplying by1 + the rateinstead of computing the balance and the fee separately and adding them. Same answer, fewer steps.
Why this and not 320 - 50 * 0.10
Without the parentheses, the query reads 320 - 50 * 0.10, which evaluates differently. SQL applies standard operator precedence: multiplication runs before subtraction. So 50 * 0.10 resolves first to 5.00, and the subtraction returns 315.00. That's the wrong calculation: a fee being subtracted from the cart total instead of the balance after a credit.
The parentheses are how the prompt's business logic — "the fee is calculated on the remaining balance after the credit is deducted" — gets enforced inside the SQL. Take them out and the query computes a different question.
The trap
Forget the parentheses on a multi-step calculation and PostgreSQL silently applies its default precedence. The query runs, returns a number that looks reasonable for an invoice line, and the finance team reconciles against the wrong figure. Any time a subtraction or addition needs to complete before a multiplication or division, the parentheses are mandatory. They control the order; without them the order defaults to PostgreSQL's precedence rules and the answer changes.
You practiced using parentheses to control the order of arithmetic — subtracting first, then applying the percentage. Parenthesized sub-expressions recur whenever a calculation has multiple stages that must run in a specific order.
