Helix Systems' accounts payable team is calculating the net amount due on a vendor invoice. The invoice is for $3,600, an early-payment rebate of $400 is applied first, and a 5% processing fee is then charged on the remaining balance.
Write a query to return the final net payment amount.
Output:
- A single row with one column,
net_payment.
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
(3600 - 400) * 1.05 AS net_paymentThe shape
The parentheses force the rebate to come off the invoice before the processing fee applies, and multiplying by 1.05 folds the fee on in one step instead of computing the post-rebate balance and the fee separately.
Clause by clause
SELECT (3600 - 400) * 1.05 AS net_paymentis a single arithmetic expression with three moving parts: a subtraction inside parentheses, a multiplication outside them, and an alias on the result.3600 - 400runs first because of the parentheses, returning3200— the balance left after the rebate is applied to the invoice. Both operands are integers, so this intermediate value is the integer3200.* 1.05then scales that balance up by 5%, adding the processing fee inline. The decimal1.05introduces a two-decimal-place scale, and PostgreSQL combines that with the integer3200to return3360.00.AS net_paymentlabels the result as the final amount due. The accounts payable team can drop the column straight into a payment file without renaming it.
Why this and not (3600 - 400) + (3600 - 400) * 0.05
Both shapes return the same 3360.00, but the inline form treats the fee as a scaling factor instead of a separate term to be added. Multiplying by 1.05 says "the result is the base scaled up by 5%"; the longer form says "the result is the base plus 5% of the base." Algebraically identical, structurally different.
The shorter form is also less error-prone. The longer form repeats (3600 - 400) twice, which means two places where the parentheses can be forgotten or the operands can drift apart if the numbers ever change. The single-expression form computes the post-rebate balance once and uses it once.
The trap
Strip the parentheses and the precedence rules quietly do the wrong thing. 3600 - 400 * 1.05 runs the multiplication first, evaluating to 3600 - 420, which lands at 3180.00. That's the invoice total minus 5% of the rebate — a number that has no meaning in the business logic but looks plausible enough to slip through a reconciliation.
The same trap shows up any time a subtraction or addition needs to happen before a multiplication or division. The parentheses are mandatory; they're the part of the syntax that encodes which calculation is supposed to run first.
You practiced using parentheses so a subtraction completes before the percentage scaling kicks in. Group operations to control evaluation order — the same recurrence shows up in every multi-step calculation.
