Purchase prices, tax, charges and currencies
Purchase costs are entered on the order. Unlike the Sales workflow, this form does not offer a sales-price estimate or manual-discount approval percentage. The server calculates amounts when saving.
One line, step by step
| Calculation | Example amount |
|---|---|
| Gross = quantity × unit price | 500.00 |
| Discount amount | −25.00 |
| Net = gross − discount | 475.00 |
| Tax amount entered for the line | +95.00 |
| Line total | 570.00 |
The 95.00 tax is an arithmetic example equivalent to 20% of 475.00, not a jurisdictional tax rule. Tax amount and Discount amount are amounts for the whole line. Entering 20 in Tax amount adds 20.00, not 20%.
The server can derive a percentage from an entered amount for its stored calculations, but the browser fields here are amount fields. Always check the saved totals after changing quantity or price; do not assume your old entered tax amount automatically represents the correct tax for the new quantity.
Header total
Grand total = sum(line gross) − sum(line discounts) + sum(line tax)
+ freight + insurance + other charges + rounding − prepaid
Base total = corresponding amounts × exchange rate
| Component | Example |
|---|---|
| Total of line amounts including tax | 570.00 |
| Freight | +20.00 |
| Insurance | +5.00 |
| Other charges | +3.00 |
| Rounding | +0.02 |
| Prepaid amount | −100.00 |
| Order grand total | 498.02 |
Prepaid amount is part of the order calculation. Entering it is not the same as recording a vendor payment or allocating one to an invoice.
The browser's header amount controls use a non-negative minimum, including rounding. A negative rounding adjustment is not offered by this form.
Prices include tax
Prices include tax is recorded on the order, but the current order calculator still calculates quantity × unit price, less discount, plus the entered tax. It does not reverse-calculate a tax-exclusive price from a tax-inclusive input.
Example: entering unit price 12 and Tax amount 2 for quantity 1 produces 14 under this calculation, not 12. Agree the correct input convention with Accounts and check the result before submitting.
Foreign currency example
Northstar quotes EUR 1,000. Base currency is GBP; the approved transaction-to-base rate is 0.85.
| Field / result | Value |
|---|---|
| Transaction currency | EUR |
| Base currency | GBP |
| Exchange rate | 0.85 |
| Transaction total | EUR 1,000.00 |
| Base total | GBP 850.00 |
Approval thresholds apply to 850, not 1,000. The application does not retrieve a live exchange rate in this form. Record the agreed date and rate; the exchange rate date cannot be after the order date.
Invoice amounts need their own review
The receipt-to-invoice routine uses accepted quantity × the PO unit price, then adds the PO line tax amount and subtracts its line discount amount. It does not proportionally split those line tax/discount amounts across partial receipts, and it does not add PO header freight, insurance, other charges or prepaid adjustments into the generated invoice total.
Example: order 200 mugs at 2.50 with line tax 100. A receipt accepting 100 mugs generates gross 250 plus the copied tax 100, giving 350. A proportional 20% illustration would instead be 300. This is why the split-delivery exercise uses zero tax and discount.
Check each generated draft against the supplier's invoice before posting. There is no invoice line-editing or matching-exception workbench in the current Purchase screens. Escalate differences to the application owner/Accounts rather than treating the generated figure as an automatic match.