A line discount reduces a particular charge. A document-level allowance is represented against the invoice as a whole under its applicable rules. Applying the same percentage to several lines may produce a similar total in a simple example, but it does not automatically express the same business or structured-data meaning.
The invoice calculation workflow makes the supported boundary explicit: the current creator has percentage discounts per line, with no dedicated document-level allowance or charge model. Preserve the agreed adjustment level before deciding whether the tool can represent the transaction accurately.
Identify what the agreement reduces
Read the adjustment terms alongside the charges. A discount on a specific equipment line differs from a general commercial allowance covering the document. A reduction might exclude delivery, apply only to one service or have conditions that cannot be inferred from a single total.
For a fictional invoice with 100.00 of equipment and 50.00 of installation, ten percent off equipment is 10.00. Ten percent off the combined 150.00 is 15.00. Entering ten percent on both rows would implement the latter arithmetic, even if the agreement intended the former.
Keep the accepted terms with the preparation record. Do not decide the adjustment level solely by choosing the easiest available field. The invoice should express the agreed transaction and any required destination representation, not merely a convenient way to reach a target amount.
Understand the current line sequence
For each row, the creator rounds quantity times price, calculates and rounds the supported percentage discount, subtracts it and then calculates line tax. It sums the resulting rounded line values. A discount entered on one row does not create a separate document-level allowance record.
If an invoice has three eligible rows, you must review any entered discount on each. Copying the value can be appropriate only when the underlying agreement and supported representation justify it. It does not automatically handle exclusions, caps, multiple discount stages or a global monetary deduction.
A note describing an overall allowance cannot change this behaviour. The document may display the note while still calculating only the supported line inputs. Check for that contradiction before export, especially if another person prepared the text and assumed it affected totals.
Consider tax-category allocation
A document-wide adjustment involving different tax treatments can require more than subtracting one number from a final total. The appropriate calculation and structured representation depend on the applicable rules and intended profile. The creator does not determine or implement such an allocation.
Do not assign the entire adjustment to an arbitrary zero-tax line to simplify the preview. Nor should you reduce a manually entered tax rate to compensate. Those changes can make the document’s values appear balanced while misrepresenting the underlying supplies and treatment.
Establish the correct adjustment basis using the appropriate evidence and requirements. If formal allowance fields, reasons or tax-category associations are needed, use a system that genuinely supports them. A matching visible total does not prove those requirements are satisfied.
Keep allowance type separate from level
An allowance can be stated as a percentage or a fixed amount, and its level is another independent fact. The guide to percentage versus fixed-amount discounts explains the mathematical difference. Do not assume every percentage belongs at line level or every fixed value belongs at document level.
For example, a fixed concession on one service still relates to that service, even though the current app cannot enter it as a dedicated fixed line allowance. A percentage applied to the whole document still has document-wide scope, even though the app offers a percentage box on each line.
Keep both facts in your preparation records: what is reduced and how the reduction is calculated. That makes later transfer into a suitable invoicing system less likely to lose the intended meaning or accidentally apply the adjustment twice.
Check the handoff to another system
If you use the creator to prepare supported data before finalising elsewhere, identify the unsupported allowance explicitly in your working records. Do not label the current preview as complete while expecting the recipient to infer a missing deduction from notes.
In the final system, check that the allowance appears at the correct level, uses the correct base and affects the appropriate totals. Review tax consequences and run any formal validation required for the intended format. These steps are separate from the creator’s field checks.
Retain both the source agreement and the final calculation evidence. When comparing versions, distinguish a change in representation from a change in the commercial amount. The current application exports its own JSON, line-item CSV and printable output; it does not provide formal document-level allowance support, routing or authority submission. Complete those requirements through an implemented and verified workflow before delivery.
One practical preparation check is to write the adjustment beside the source agreement before entering any rows: its type, scope, base and exclusions. If those four facts cannot be expressed by the available line percentage control, mark the draft as needing another finalisation workflow. This makes the limitation visible before another reviewer assumes the displayed total already includes every agreed reduction.