Reconcile an invoice by checking the inputs and the calculation sequence, not only the final total. Start with each quantity and unit price, apply the supported line discount, review the resulting net amount and tax, then compare the summed document amounts. A plausible total is not proof that the underlying charge is correct.
You can use the invoice creator to enter ordinary positive invoice lines and see the amounts update. The current model supports percentage line discounts and manually entered line tax information. It does not implement document-level allowances, prepaid deductions, withholding, currency conversion or formal standards validation. Those boundaries matter when comparing its result with another system.
Establish the amount basis first
Before calculating, identify the agreed quantity, unit and price for each supply. A rate per hour cannot be combined with a quantity measured in days without an agreed conversion. A price per box cannot be used with a count of individual products unless the basis has been resolved.
Keep the accepted quote, order or approved service record available during review. The creator cannot verify that a number came from the correct agreement. Its field validation checks supported input rules and required values, while commercial accuracy remains a separate review responsibility.
Do not adjust an input merely to force the final total to match an expectation. A mismatch can be useful evidence of a missing line, duplicated charge, different discount or rounding policy. Investigate the cause before changing the transaction data. The guide to unit price and line amount starts with these distinct roles.
Understand the supported precision
Quantities may have up to four decimal places. Unit prices have up to two decimal places, and discount and tax percentages have up to two. All currencies currently offered by the creator use two-decimal money handling in this application. The currency selector does not change the calculation into a different precision model.
A source value needing greater precision cannot be preserved by putting extra digits into a note. Determine whether an agreed alternative basis can be represented faithfully. If not, use a system that supports the required precision. A shorter number may look harmless while changing the line amount on a large quantity.
The app uses fixed-point arithmetic for its supported inputs. That avoids relying on ordinary floating-point results for the monetary calculation, but it does not make every possible invoice model supported. You still need to check quantity, rate, adjustment structure and destination requirements before treating the result as suitable for delivery.
Follow the line calculation in order
The creator first multiplies quantity by unit price and rounds that initial amount to cents using half-up rounding. It then calculates the percentage discount from that rounded amount, rounds the discount to cents and subtracts it. The result is the line net amount used for the supported tax calculation.
Tax is calculated from that discounted net amount using the manually entered supported rate, then rounded to cents. The app sums these rounded line values for the document. A calculation that retains every unrounded intermediate value until the very end can produce a different result, even when the initial inputs are identical.
For a straightforward fictional line, quantity three at 18.00 gives 54.00. A ten-percent discount is 5.40, leaving 48.60 net. At an illustrative manually chosen rate of twenty percent, tax is 9.72 and the line contributes 58.32 including tax. The illustrative rate is arithmetic only, not a recommendation for any transaction.
Review discounts as explicit inputs
A percentage discount changes the amount on the selected line. It is not a fixed monetary reduction and does not apply automatically to the whole invoice. Check each row against the agreed discount scope, especially after copying or adding lines with different services.
The guide to how a line discount changes net amount explains the current sequence in detail. If an agreement instead specifies a fixed allowance, a document-wide reduction or several adjustments, do not force those facts into a percentage field without verifying whether the supported model can represent them accurately.
The current creator does not provide document-level allowance or charge fields. A negative line is also outside its ordinary positive-invoice model. Notes can explain facts, but they do not alter the calculation. Use an appropriate system for unsupported financial arrangements instead of making the preview imply that the adjustment has been implemented.
Reconcile the document from its lines
Make a review record showing each line’s net amount and tax. Sum the net amounts to the document’s net subtotal, sum the rounded line tax amounts and add the two totals. Compare that result with the preview. This separates a line-input problem from a document-addition problem.
The guide to reconciling subtotal, tax and total provides a worked multi-line check. Review the tax categories as well as the numbers. A zero tax amount may have several different explanations, and the app does not determine whether the manually chosen category or rate is correct.
Do not subtract a prior payment from a line price merely to show a lower outstanding balance. The current model has no prepaid reconciliation. Its total represents the supported invoice calculation, not an account statement containing payments, credits or other ledger adjustments. Preserve those facts separately for a suitable final workflow.
Investigate rounding differences deliberately
A one-cent difference often comes from the stage at which a value is rounded, but it can also reveal a different input. Compare the exact quantity, price, discount, rate and line grouping before concluding that rounding is responsible. A displayed two-decimal result can hide different internal assumptions in another system.
Use the per-line rounding guide to understand the mechanism and the cross-system investigation checklist to compare two results. Keep the policies and intermediate values with the review record. Do not change a quantity, tax category or price solely to suppress a difference without an agreed and supported basis.
A formal structured profile may define calculations and business rules beyond the current application’s model. Matching a visible total is not proof of compliance with those rules. If a recipient requires such a profile, complete the required mapping and formal validation in a system that implements it.
Recalculate after every meaningful revision
Removing a row changes the subtotal and its tax contribution. Editing quantity may change the rounded discount as well as the initial amount. After any such revision, repeat the relevant line checks and inspect notes that contain old amounts. The numeric preview updates; free text does not.
Run application field validation before final export, repair supported-field issues and download a fresh file after the last edit. The app’s JSON is its own invoice-data schema, CSV contains line items and print uses the browser. None of these outputs establishes legal validity, authority acceptance or delivery through a structured-invoice network.
Keep the final inputs, reviewed result and supporting agreement together under your normal business record process. A reproducible calculation lets you explain the invoice and investigate later questions. It also makes remaining limitations visible before the document is transferred into another system or sent to a recipient with more specific requirements.
For a large draft, keep a simple control sheet with one row per billed supply and columns for its source reference, quantity, rate, rounded net and tax. Mark the review date and the version exported. This sheet is an internal checking aid, not another customer invoice. It helps identify whether a later difference came from changed source data, a revised agreement or a calculation-policy mismatch, without relying on memory of the editor’s earlier state.