Write an invoice line description so the customer can connect it to something they ordered or received. Name the product or service, then add the distinguishing detail needed to recognise that particular supply. A useful description supports review; it should not require the customer to search an old conversation simply to understand the charge.
Description writing is one part of the line-item preparation workflow. Before polishing the wording, confirm that the row represents the right product or service and that its quantity and pricing basis are correct. Clear language cannot repair an incorrectly grouped charge or a price taken from the wrong agreement.
Start with the supplied item
Use the name the customer recognises. For goods, a model, size or variant can distinguish similar items. For services, state the agreed activity or deliverable. “Quarterly server maintenance, branch office” tells a reviewer more than “Professional services”, while remaining short enough to work as an invoice line.
Avoid replacing the item name with a project nickname known only to your team. If the customer uses an agreed project label, include it alongside the actual service. That combination lets a project manager recognise the work and gives an accounts reviewer enough context to route questions without interpreting your internal terminology.
Do not add claims that the source record cannot support. A description saying “completed installation” means something different from “installation deposit” or “equipment supplied”. Confirm the stage being billed before choosing words that imply delivery, acceptance or completion. The app does not verify those business events.
Make the description agree with the fields
Suppose a line represents six hours of configuration at 48.00 per hour. Put six in quantity, hour in the unit field and 48.00 in unit price. The description can identify the system and configuration task. It need not restate every numeric value, which creates extra text to update when the draft changes.
If you do include a quantity or rate in prose, compare it with the fields before export. A description saying “five support hours” beside a quantity of six is a visible contradiction, even when the calculation is mathematically correct. Field validation does not interpret prose and cannot reliably detect that mismatch.
A fixed package should use the agreed package basis. Do not label it hourly merely because your team tracked internal time. Customer-facing quantity and price should express the commercial agreement rather than the way your business measured its own effort or estimated its margin.
Include only distinguishing detail
Ask what could make the recipient confuse this line with another one. A product variant, work location, delivery batch or service period may resolve that ambiguity. Include that detail when it is relevant and accurate. Do not copy an entire proposal into the field simply because it contains a description of the work.
For recurring services, a period can help distinguish one month’s charge from another. Use a clear written date range when describing it. The current creator has no dedicated structured line-period fields, so dates written in a description remain text. They do not establish a formally mapped service period in an exported standard.
Keep bank details and payment instructions out of item descriptions. They belong with the payment information. Similarly, a tax reason should use the supported tax-reason field when relevant. Separating these facts helps prevent outdated instructions from surviving inside a line copied from an earlier draft.
Decide when one description is doing too much
A description covering design, printing and delivery may be describing one agreed package, or three separately priced supplies. Check the order rather than choosing the layout that happens to look shorter. If the components have different quantities, rates or tax treatments, one row can obscure the basis of the calculation.
The guide to separating different services into lines explains how to make that grouping decision. Once the structure is settled, write each description to identify its own charge. Avoid repetitive paragraphs that imply every row covers the entire project when each amount actually relates to only one part.
Review the exported reading experience
Read the preview without the order document beside it. Can you identify what was supplied, distinguish the rows and understand the amount basis? Then compare it with the source record. This two-pass review catches both vague wording and confident wording that describes the wrong supply.
Check long descriptions in the print preview as well as the editor. A sentence may wrap across several lines and make neighbouring values harder to follow. Shorten redundant phrases while keeping the facts needed to recognise the supply. Do not use abbreviations that only save space by making the document unclear.
You can try the invoice creator with a short fictional description before entering real customer information. Review how the wording appears beside the numeric fields, then revise it. Keep the final wording consistent with the approved commercial record. The current tool provides a readable preview and application exports; its description field does not classify goods, choose tax treatment or guarantee acceptance by the recipient’s invoicing system.