Enter your idea

At a minimum, references and line-item descriptions should remain editable on paid invoices, and this functionality should be reinstated for paid or refunded customer credit notes.

Accounting integrations and connected e-commerce platforms cannot always determine the correct account, tax rate or description for every invoice or credit-note line.

Some platforms also make it difficult to assign the correct tax treatment to every individual product or product type before the transaction is sent to Xero. This is particularly difficult where one order contains items with different GST treatments, or where an order is subsequently edited, discounted or partially refunded.

For example, when an order is edited in Shopify to apply a discount to a GST-free product, the integration may:

• apply the wrong GST treatment;
• describe the adjustment as “Surcharge adjustments”;
• enter the shipping line as a negative discount; and
• add a separate adjustment line to bring the credit note back to the correct total.

The final invoice or credit-note total may be correct, while the individual lines, descriptions, accounts and tax rates are wrong. Our integration fortunately sends a notification when it has had to estimate or guess the treatment, allowing us to identify the affected transactions.

Xero should allow users to fully edit the line items of a paid invoice or credit note while keeping the following fields locked:

• total transaction amount;
• transaction date;
• contact; and
• payment, allocation and bank account used.

As long as the settled total remains exactly the same, users should be able to:

• edit line descriptions;
• edit the reference;
• change accounts;
• change the tax rate on individual lines;
• change line amounts and quantities;
• delete unnecessary or artificial lines; and
• add replacement or correcting lines.

This would allow an integration-generated transaction to be corrected accurately without changing the amount paid or refunded, disturbing the payment allocation or undoing a correct bank reconciliation.

For a small number of affected transactions, directly editing the invoice or credit note would also be much simpler and more efficient than having to create and run a complex series of Find and Recode searches. Find and Recode is useful for correcting large groups of transactions with the same issue, but it is unnecessarily cumbersome where only a few invoices or credit notes contain different combinations of incorrect lines, tax rates or descriptions.

At the very least, references and line-item descriptions should remain editable after an invoice or credit note has been paid. This would allow a user to add a clear note identifying what needs to be corrected later. The affected invoices or credit notes could then be located in a monthly Find and Recode review by searching the reference or description, making it possible to recode similar errors in bulk.

Without this minimum level of editing, a user may know that a credit note has the wrong GST treatment or account coding but have no practical way to identify the required correction when reviewing the affected transactions later in Find and Recode.

Where a user attempts to change the total, date, contact or payment details, Xero could continue to require the payment to be removed or adjusted. However, when those locked fields remain unchanged, there is no reason to require Remove & Redo merely because the internal composition of the transaction needs to be corrected.

Any changes could continue to be recorded in History & Notes, preserving a clear audit trail of the original integration-created lines and the subsequent corrections.

This functionality is increasingly important in an e-commerce accounting environment. Integrations frequently have to estimate the purpose, tax treatment or account coding of discounts, refunds, shipping adjustments and other order changes. Locking all line-item details once the total has been paid prevents users from efficiently correcting known integration errors.

The payment should lock the amount and transaction identity that were settled, not permanently lock incorrect descriptions, tax treatments, accounts or artificial line-item structures created by an integration.