After adding or removing an invoice line, reread the remaining sequence and any text that refers to particular rows. A row’s screen position is a convenient way to find it during editing, but it is not automatically a stable business identifier or a purchase-order line reference.

This review belongs in the line-item workflow before you trust the final totals. The current creator supports editable rows and recalculates amounts after changes. It does not provide a dedicated workflow for managing persistent structured line identifiers or mapping buyer order-line identifiers into a formal standard.

Separate position from identity

The first row is simply first in the current document order. If it is removed, the next row becomes first. That change should not imply that the underlying product, service or external order reference has acquired a new business identity.

A note saying “delivery included with item 2” can therefore become misleading after an edit. Where a textual reference is needed, use enough descriptive context to identify the intended supply. Then check the reference again after the line structure changes.

Do not assume the app exports a formally mapped invoice-line identifier just because the editor shows rows in order. Structured profiles can define their own identifier requirements. If the receiving workflow requires such fields, use a system that implements and validates those requirements.

Review additions for duplication

When you add a new row, confirm whether it represents an additional charge or replaces an existing one. It is easy to enter a corrected description and price in a new row while leaving the original charge behind. Each row may pass validation while the document bills the service twice.

Compare the new sequence with the source order or approved scope. Tick off the actual supplies in a separate review record if the invoice is long. Do not rely only on the total, since a duplicated low-value item may be hidden within a larger document amount.

Inspect copied fields on the new row: quantity, unit, discount, category, rate and reason all matter. A descriptive change alone does not make the numeric basis appropriate for a different service. The live preview shows the consequences of the inputs, not whether the added charge was authorised.

Review removals for missing context

Before removing a row, identify what it contributed commercially as well as financially. A package description might refer to an accessory shown separately. Removing the accessory line may leave the package wording incomplete or make the remaining document unclear about what was supplied.

After deletion, check notes, descriptions and references for phrases such as “above”, “below”, “second item” or “remaining three lines”. These may no longer point to the intended content. The application does not interpret those phrases or repair their meaning automatically.

If the removed row related to a separately agreed delivery or service, retain the reason for omitting it from this invoice. It may belong on a later document, require a correction or no longer be billable. Row deletion alone does not record that business decision in an account history.

Recheck the calculation basis

The subtotal, tax and total should change according to the removed or added row’s actual amounts. Review the line discount and tax contribution rather than comparing only quantity times price. A discounted row can contribute less than its initial gross amount, and its tax depends on the supported category and rate.

Check any remaining narrative total written in notes. The app recalculates supported numeric totals, but it does not rewrite a sentence that says “package total 900.00”. Remove or update conflicting text after the line change.

Do not use a removed row as an informal way to record a credit against an earlier invoice. The current app supports positive invoice preparation, not a credit-note ledger or formal correction workflow. Use the appropriate process when the business event is a correction to a document already issued.

Inspect exports after the final sequence is stable

Use the line-item checklist to review all remaining rows before a final export. Confirm that the visible scope matches the accepted source records and that no textual reference depends on an earlier row arrangement.

If you already downloaded a draft or final file before editing, create a fresh export after the change. Existing downloaded files do not update themselves. Keep your record handling clear so the intended final version is not confused with an earlier version containing the old sequence.

Finally, inspect the preview and browser print output for the revised document. A shorter invoice may wrap differently, and a newly added long row may affect pagination. Application field checks remain useful, but they do not validate external order-line matching, stable identifiers or the recipient’s formal processing requirements. Verify those in the appropriate delivery system before submission.

If the customer provided numbered order lines, keep a separate comparison record while preparing the invoice. Check that an insertion or removal has not shifted your informal cross-reference to the wrong ordered item. A screen position should never be the sole evidence connecting a billed supply to that external record.