Prepare a product-sales invoice from the goods actually being billed, the agreed quantities and prices, and the customer’s billing instructions. Start with the order and relevant delivery records rather than a previously issued invoice. Similar orders can differ in pack size, partial delivery, discount arrangements or the legal entity being charged.
For a simple sale, the current creator can hold ordinary positive item lines, manually entered tax information and payment instructions. It does not manage inventory, verify deliveries or generate recognised standards-based e-invoices. The first-invoice preparation workflow explains the complete process; the checks here concentrate on the goods and charging basis.
Match the invoice to the relevant delivery
Identify which order, shipment or accepted delivery the invoice concerns. An order for twenty units does not prove that twenty units are ready to bill if only twelve have been delivered and the agreement bills on delivery. Confirm the billing event and quantity using the appropriate records.
Keep an unbilled balance outside the invoice unless the transaction and document type explicitly require it to be shown. Do not use a free-text note to imply that an unsupported inventory or delivery-tracking function exists. The creator calculates line entries; it does not reconcile an order automatically or decide what should be billed next.
Check the buyer entity and address independently of the delivery location. Goods may arrive at a warehouse operated for several group companies. A warehouse name on a dispatch record should not automatically replace the customer legal entity from the billing instructions.
Describe products so the customer can match them
Use a recognisable product name and the variant needed to identify the supply. A size, model or finish can distinguish products with similar names and different prices. An internal nickname meaningful only to the seller may create avoidable questions for the buyer.
Where an order uses product codes, preserve the code and its role in your preparation records. The current editor has a description field rather than a separate typed product-identifier structure. Including a code in a readable description may assist human matching, but supporting software may need a dedicated identifier field and scheme for a structured recipient profile.
If products are grouped, confirm that the grouping does not hide different unit prices or tax treatments. A line labelled “assorted supplies” may be insufficient where the customer needs to match individual order items. Separate lines should reflect meaningful differences, not simply add length to the document.
Confirm what one unit means
Suppose a fictional stationery supplier sells six packs of labels at EUR 8 per pack, with fifty labels in each pack. For that agreement, quantity 6, unit “pack” and price 8.00 produce EUR 48 before discounts and tax. Quantity 300 with price 8.00 would imply charging the pack price for each individual label.
If the contract instead prices individual labels, use the unit and price appropriate to that agreement. Do not change the unit label without revisiting the quantity and unit price. All three fields express one charging basis, so a change to one may require changes to the others.
The application accepts free-text units for its own invoice model. That does not establish that a target standard accepts the same word as a unit code. Retain the intended meaning so an external mapping can select a permitted code without guessing what the seller counted.
Preserve adjustments and tax facts
Record the agreed line discount separately from the unit price when that matches the arrangement. Do not use a discount to conceal a returned product or a prepaid amount. A credit note, return adjustment or advance-payment reconciliation may require a document type and fields that this creator does not implement.
The current model also lacks document-level shipping charges. If delivery is a separately supplied, agreed item, assess the proper representation and confirmed tax treatment with appropriate advice. Do not assume that adding a generic shipping line always reproduces the required accounting or tax structure of every transaction.
Enter only the tax category, rate and reason confirmed for the actual supply. Similar goods can have different treatment depending on facts the editor does not know. Passing the application’s category and percentage checks does not establish the correct legal classification.
Reconcile the totals and the output
For each line, compare quantity and unit price with the source order. Check any discount and the resulting net amount. Then review the tax breakdown and total. A correct total for the wrong pack size is still the wrong invoice, so reconciliation must inspect the charging basis as well as the final number.
If your invoice also contains services, the service-invoice preparation checks can help separate hours or milestones from units of goods. Avoid using one vague unit across all lines for convenience.
Once the records agree, you can build and review the product invoice in the creator. Inspect the preview for clear descriptions, correct parties and the right currency. Run the field checks, then choose an available output suited to the next step.
Printing and browser Save as PDF produce readable output, application JSON preserves the application’s data, and CSV provides line items. If the customer requires a specified XML or hybrid format, finish that mapping and validation in supporting software. Keep the order and delivery evidence with the reviewed export so future questions can be resolved from the facts rather than reconstructed from the document alone.