A useful invoice line identifies what was supplied, how much was supplied and the basis for its price. Start with the agreed transaction, then separate those facts into the fields the creator supports. Clear descriptions help a person review the document. Separate quantities, prices and other values help software calculate the amounts without interpreting sentences.
You can open the invoice creator to assemble an ordinary positive invoice with editable lines, a document preview and application-level field checks. Its current exports are application JSON, line-item CSV and printable output. Preparing clear lines does not establish conformity with an e-invoicing standard, and the current creator does not export a formally mapped standards document.
Gather the evidence for each charge
Use the accepted quotation, order, delivery record or approved timesheet to identify the work being billed. Avoid beginning with a total and inventing descriptions that make the total appear reasonable. You should be able to explain where each quantity and price came from without relying on the finished invoice as its own evidence.
For a small equipment order, record the model, quantity delivered and agreed unit price. For consulting, record the activity, approved time and rate basis. Keep supporting evidence in the business records where it belongs. The creator is an invoice preparation workspace, not a delivery-record or timesheet management system.
A draft can reveal missing information. If you know that three items were supplied but do not know the agreed price, resolve that uncertainty before export. A field accepting a number only proves that the number fits the application’s input rules. It does not verify the contract or the recipient’s acceptance of the charge.
Choose a line structure before entering prices
Create separate lines when the supplied items have different commercial identities, prices, units or tax treatments. Do not create a separate line for every sentence in a scope of work if the customer purchased one fixed package. The appropriate grouping follows the agreement and the information needed to review the charge.
For example, a design package charged at a fixed amount and separately billed support hours usually need different quantity and price bases. Two paragraphs describing the same fixed package may belong in one description. The guide to separating different services develops this decision without turning an invoice into a project task list.
Decide the grouping before adding discounts. Otherwise, a single discount entered against a combined line may apply to work that was not meant to receive it. Similarly, a single tax selector cannot express several distinct tax treatments inside one line. Resolve those differences in the line structure rather than burying them in explanatory prose.
Write descriptions a reviewer can recognise
Begin with the supplied item or activity. Add the specification, location or period that distinguishes it from similar purchases. Prefer “Replacement filter cartridge, model RF-8” over “Goods as discussed”. For services, identify the agreed work rather than copying an internal employee task label that the customer has never seen.
A description should remain understandable beside the quantity and unit. “June support, 12 hours” is less useful if the quantity field says one and the price is an hourly rate. Let the numeric fields express the calculation and use the wording to identify the service. The detailed guide to recognisable line descriptions includes checks for this relationship.
Do not use a description as the only location for a purchase-order identifier, tax reason or payment instruction when an appropriate supported field exists. Where the necessary typed field is absent, preserve the requirement in your preparation records and choose a tool that implements it for the final delivery workflow. Text alone does not create a missing structured field.
Match the quantity to the unit price
A quantity of eight at a price of 35.00 means something different when the unit is hours rather than packages. Confirm whether a price applies to one item, one pack, one hour or a complete engagement. Convert the quantity and price basis together if the agreement is expressed differently from your draft.
The creator accepts positive quantities with up to four decimal places, and nonnegative unit prices with up to two decimal places. It uses a single price per entered unit. It does not provide a separate price-base quantity for contracts priced per hundred items. Do not assume a unit label performs that conversion automatically.
For time-based work, an hour and a day are separate charging units. A day should not be converted to eight hours unless that is the agreed commercial basis. For weighed or measured goods, retain the measurement evidence and agreed precision. The guide to fractional quantities explains how to preserve useful detail within the current input limits.
Distinguish labels from structured codes
The unit field is editable text for the current invoice model and preview. Writing “hour” there makes the unit readable. It does not create a validated code from a standard code list or prove that a recipient’s software will recognise the value as a formal unit identifier.
In Peppol BIS Billing, the invoiced quantity has a unit-code attribute governed by a specified code list. That is a profile-specific mapping requirement, not a feature provided merely by displaying a unit beside a number. Read unit labels versus standard unit codes before preparing data for another system that requires coded units.
The same distinction applies to item identifiers. A stock code included in a description is visible to a reader, but it is not automatically a seller-item identifier field. Keep any required buyer code, seller code or standard identifier separately in the source records so a future export adapter or appropriate invoicing system can map it accurately.
Use the preview as a review surface
After entering the lines, read the document in the order a recipient will encounter it. Check that descriptions wrap cleanly, quantities align with their units and amounts correspond to the intended services. A long line that looks acceptable on a wide screen may need closer inspection in the browser print preview.
Add and remove lines deliberately. A row’s position in the editor is not evidence of an order-line identifier, and removing a row changes the totals. Re-read the remaining sequence and verify that no explanatory statement still refers to an item you deleted. Use the line-item review checklist before treating the calculation as complete.
Avoid entering confidential internal commentary just because there is room in a description. Anything included in the exported document may reach people beyond the initial contact. Keep approval disputes, internal margins and staff performance comments outside customer-facing invoice data unless there is a specific authorised business reason to include them.
Finish the line review before final validation
Once the line structure is stable, check the quantity, price, percentage discount and manually selected tax information for every row. The creator recalculates the preview as values change. That is useful feedback, but a plausible total can still arise from the wrong quantity or price, so inspect the inputs as well as the result.
Resolve missing values and unsupported requirements before using a final export. Application validation checks supported field rules; it does not determine tax treatment, validate a destination’s schema or submit the invoice. Save an editable draft when you need to continue preparation later, and protect downloaded invoice files using your normal business handling practices.
If a recipient requires typed item identifiers, coded units, line periods or a formal standards file that the creator does not implement, treat your current work as preparation. Preserve the underlying facts and use a verified tool for that delivery requirement. The useful outcome is a clear, internally consistent invoice draft whose remaining limitations are understood before it is sent.