An invoice preview helps you review the visible document: identities, references, descriptions, currency, amounts and payment instructions. It can reveal a wrong buyer, an unclear line or a number that does not match your records. It cannot prove that the underlying data meets a recognised standard, that the tax treatment is correct or that the recipient has received the invoice.
Treat the preview as one review surface alongside the source records and the intended export. The first-invoice workflow uses all three. If you inspect only the page appearance, you can approve a readable document whose data or delivery requirements remain unresolved.
Read the preview in a repeatable order
Start at the top with the invoice reference, issue date, due date and buyer reference. Compare these with the allocated reference and customer instructions. Then check the seller and buyer identities, including addresses and identifiers where shown. A familiar company logo or professional layout should not distract from the exact entity being billed.
Read each line description before looking at its amount. Confirm that the description identifies the supplied goods or work, the unit matches the charging basis and the quantity is the approved quantity. A neat line showing “12 days” is still wrong if the agreement concerns twelve items.
Review subtotal, discounts, tax breakdown and total separately. Two offsetting errors can leave a believable grand total. Finish with payment instructions and notes, where sample references or outdated bank details can be less noticeable than the main invoice number.
Use the source records to interpret the page
The preview can display what you entered; it cannot independently reconstruct the agreement. For a fictional designer, five hours at GBP 65 produce GBP 325 before any discount or tax. If the agreement permits only four hours, the correct visible multiplication does not establish a valid charge.
Compare the preview with approved hours, an order or the relevant delivery evidence. Check that the currency and tax basis match the agreement. A currency symbol or a line labelled “net” can help a reader understand the intended basis, but neither verifies that the commercial inputs were entered correctly.
If the customer supplied several references, check which ones the preview actually shows and where. The current model contains one general buyer reference. It cannot represent every typed procurement reference required by every recipient profile. A readable note can preserve context for a person without satisfying an external field-mapping requirement.
Distinguish visible content from complete data
Some data formats can carry fields that a particular preview does not display. Conversely, a printable document can show explanatory text that has no structured equivalent in the target data. Review both representations when another system will consume the invoice information.
In the current creator, the JSON export contains the application model and computed totals. The line-items CSV has a narrower purpose and does not contain the full party record. A preview containing seller and buyer details does not mean those same details exist in every available download.
A hybrid invoice has another consistency question: its readable representation and embedded structured data must be reviewed together under the relevant specification. EInvoiceCreator does not currently generate that hybrid output. A browser-generated PDF from its print dialog should not be described as containing standards XML merely because the screen showed a structured-looking invoice.
Recognise checks that the page cannot perform
A visual preview cannot verify registration of a tax identifier, ownership of a bank account, invoice-number uniqueness or the customer’s internal routing rules. It also cannot decide whether an exemption or other tax treatment is legally appropriate. Those tasks require separate records, tools or advice.
Application field validation answers a narrower set of questions, such as whether a required value is present or a date is valid. Formal standards validation evaluates a chosen specification and applicable business rules. A recipient may apply further checks to prices, order references or the transaction itself.
The separate creation, validation and delivery stages help distinguish these results. Do not replace a formal validation step with a screenshot of a document that looks complete, and do not interpret the absence of visible errors as proof of acceptance.
Inspect the actual print or download
The live preview is not the final print result. Browser paper size, margins, scaling and page breaks can affect the exported document. Open print preview, confirm that all lines and totals are present, and check the document produced by Save as PDF when your browser offers it.
For long descriptions, check wrapping rather than shrinking the page until the text becomes unreadable. If a large invoice spans pages, confirm that essential information and the total are intact. The current creator’s print styles are designed around the invoice document, but browser behaviour still needs review on the actual output.
After downloading JSON or CSV, confirm that you selected the correct file type and version for the next task. Do not rename a file extension to imitate a different output. Changing a name does not change its structure, contents or validation status.
Keep the review outcome specific
A useful review note can say that the visible buyer, lines and totals match the source records and identify the exact file reviewed. It should also name any remaining external mapping or delivery step. This is more informative than saying that the invoice “looks compliant”.
When you revise a value, revisit the affected parts of the preview and output. A changed quantity affects calculations; a changed buyer may affect references and format requirements. The preview is most valuable when it supports that evidence-based review, rather than acting as a final appearance badge.