Use a line note for supplementary explanation, not as the only place to store a fact needed for calculation or processing. A quantity hidden in a sentence cannot replace the quantity field. A discount mentioned in a comment does not reduce the amount unless the supported calculation fields express it.
The line-item preparation workflow separates identification, measurement and money values. The current creator has a line description, a tax-reason field where relevant and document-level notes. It does not have a dedicated general line-note field. Keep that boundary clear when deciding where additional wording belongs.
Decide what the information actually does
Ask whether the information identifies the service, explains a supported tax category, changes the amount or provides optional context. These roles need different treatment. A product variant belongs with identification; a numeric discount belongs in the calculation; payment instructions belong with payment details.
For example, “Colour approved by customer on 3 September” may be supplementary context for a custom product. “Quantity includes two extra units” changes the meaning of the supply and should be reconciled with the quantity field. Calling both statements notes can conceal the importance of the second.
If a fact is essential to the recipient’s automated process, determine whether the destination requires a typed field. Text can help a reader, but it does not create structured meaning by itself. Keep any unsupported required fact in your preparation records until it can be mapped in a suitable system.
Use the supported fields first
Enter the billed quantity, unit price and percentage discount in their respective controls. Review the resulting amount. Do not write “less 10 percent” in the description while leaving the discount at zero, because the displayed calculation will still use the undiscounted value.
Use the supported tax-reason field for a reason associated with a relevant tax category. Do not use that field for delivery comments or internal messages. Its purpose is different, and filling it with unrelated text can make the tax explanation less useful to a recipient.
A purchase or buyer reference belongs in the supported reference field when appropriate. The app has a limited general reference model, so it cannot express every typed reference a formal profile might require. Do not assume adding labels inside notes provides the missing typed fields.
Handle supplementary line context honestly
When a brief explanation is needed for one line, a concise addition to the description may be the current readable option. Make the item identity clear first, then add the relevant context. Remember that the entire value remains one description string in the app’s exports.
Avoid writing a paragraph that repeats the agreement or includes confidential internal commentary. The invoice may be shared with purchasing, finance and external advisers. Include only information that belongs in the customer-facing document and that you are authorised to disclose.
If you use document notes to explain a particular row, identify the row by a stable descriptive reference rather than relying only on its current screen position. Rows can move in the reader’s attention after additions or removals, and the current model does not provide a dedicated stable line-identifier workflow.
Check whether a note is hiding an unsupported feature
“Deposit already paid” is not the same as a supported prepaid-amount deduction. “Delivery charge 15.00” does not add that amount to totals. “Convert to dollars” does not perform currency conversion. A note can state an intention while the actual calculation continues to represent something else.
Do not export a document whose prose and totals disagree. Resolve the transaction in a system that implements the necessary adjustment or structured field. Keeping an explanation in the preview does not make an unsupported feature safe or complete.
Similarly, a note stating a standard or format name does not make the output conform to that standard. The creator exports its own JSON, line-item CSV and printable output. It does not perform formal schema, semantic or recipient-profile validation.
Review the note after edits
When a quantity, date or discount changes, reread the surrounding explanation. Notes can become stale because they are not recalculated. A statement referring to a removed item or an old amount can survive even after every supported numeric field has been corrected.
The guide to reviewing lines after additions and removals explains how to inspect the remaining sequence. Include notes in that review, especially when they refer to “the second item”, “the above service” or a previous total that no longer describes the document.
Before export, read the invoice as a recipient who has no access to your editor. Essential facts should be easy to find and consistent with the fields and totals. Preserve supplementary evidence in your business records rather than forcing every detail into the invoice. If a required line-note structure is part of the destination’s format, use a tool that genuinely implements that structure and checks the resulting document.
For a long invoice, maintain a short preparation list of unsupported requirements before final review. Mark which information is merely explanatory and which needs a destination field. This makes it less likely that a convenient note will be mistaken for completion of a required export feature.