Before relying on invoice totals, check that every line represents the right supply on the right charging basis. A total can be calculated correctly from incorrect inputs. Review descriptions, quantities, units, prices, discounts and manually entered tax information against the accepted records, then inspect the resulting preview.
Use this checklist as the final line-level stage of the line-item workflow. It is a practical review process, not formal standards validation or tax approval. The current creator checks supported field rules and recalculates amounts, but it cannot verify the agreement, delivery evidence or destination requirements for you.
Check what each row represents
Read each description and identify the corresponding order, delivery or approved service record. Confirm that the product variant or service scope is recognisable. Avoid generic wording that could cover several unrelated charges without telling the recipient which one is being billed.
Look for duplicated scope. A fixed package description and a separate row might both include the same setup work. Conversely, a line removed during editing might have been the only place a supplied accessory appeared. Reconcile the full set of rows with the actual transaction, not just the expected document total.
Check any stated periods, locations and references. The current creator has no typed service-period or dedicated item-identifier fields, so values written in descriptions remain text. Preserve any required structured facts separately if the final delivery system needs to map them into dedicated fields.
Check quantity and unit together
For every quantity, ask what is being counted or measured. Three boxes, three individual products and three hours are different statements. Confirm that the unit price applies to the same unit. Do not assume an editable unit label performs pack conversion or time conversion.
Review fractions against the source evidence. Minutes need conversion to decimal hours, and measured goods may need more than two decimal places. The app supports positive quantities up to four decimal places. If the required precision cannot be represented, resolve that limitation before final delivery.
Whole-number quantities deserve review too. A plausible number may have been copied from an order rather than the delivery being billed. Check partial deliveries and earlier invoices outside the creator, which does not connect to stock records or an account ledger.
Check the price and adjustment basis
Compare each unit price with the accepted agreement, including whether it is a price per item, package or time unit. The current price field supports two decimal places. A source rate needing greater precision cannot be preserved by silently rounding it or placing extra digits in the description.
Review percentage discounts line by line. Confirm that the reduction applies to the intended supply and has not been copied onto an excluded service. The current app does not implement fixed-amount discounts or document-level allowances, so those arrangements need an appropriate supported workflow.
For any zero-priced row, establish whether it is intentional or an unfinished input. Keep its commercial reason supported. Do not use zero prices, negative workarounds or explanatory notes to simulate a credit note, prepaid deduction or another financial feature the current model does not implement.
Check tax information independently
Confirm the manually selected category, rate and any required reason for every row. The country context does not choose a tax profile. The app’s field validation does not determine whether a rate, exemption or outside-scope treatment is correct for the transaction.
Where different supplies need different treatments, make sure the line structure can express those differences. The guide to separating different tax treatments explains the one-treatment-per-line limitation. A description containing several tax statements does not make the calculation split the amount accordingly.
Retain the evidence for the chosen treatment in your records. A zero tax result alone does not explain the legal or commercial basis. If the intended destination requires tax fields or calculations beyond the current model, use a suitable final invoicing system rather than relying on a readable note.
Check the preview and export version
Read the document after the rows are stable. Look for stale quantities in prose, references to deleted rows and long descriptions that separate important context from the amount. Open the browser print preview if you intend to print or save a PDF through the browser.
Run field validation and repair the reported supported-field issues. Then create a fresh export so the file reflects the final edits. Downloaded files do not update when the workspace changes. Protect the file and keep the intended final version distinguishable from drafts.
You can return to the invoice creator to revise the lines before exporting its application JSON, line-item CSV or printable document. These outputs help you use the prepared data, but they are not formal standards exports. Complete any required mapping, formal validation and delivery steps in a system that genuinely supports the destination before treating the invoice as submitted or accepted.
For a long document, review one field across all rows before reading each complete row again. Checking every unit together can expose a copied label, while the second pass catches relationships between fields. Use both passes as a practical aid, rather than relying on visual familiarity with the draft.