Use a sample invoice to learn the interface, then replace every example value before using the document for real billing. Changing the seller name alone is insufficient. Buyer details, dates, references, line descriptions, amounts, tax choices, payment instructions and notes may all contain fictional information. The purpose of the sample is to demonstrate the workflow, not to supply a legally appropriate template for your transaction.
In EInvoiceCreator, opening the filled example loads fictional seller and customer details and illustrative service lines. Those values are deliberately recognisable as a demonstration. The first-invoice workflow explains how to prepare confirmed information separately, so that the exercise does not become a process of guessing replacements as you encounter each field.
Decide whether to practise or prepare
If you only want to understand how quantities change totals, keep the sample clearly fictional. Change a quantity, add an item, remove it and observe the preview. You can learn what a control does without entering any private customer information. Do not send the practice document to a real customer or use its tax rate as a recommendation.
When you are ready to prepare an actual invoice, choose between replacing the sample systematically and starting a blank document. A blank start is often easier if every detail differs. Editing the sample can be useful when you want to follow the order of its fields, but only if you perform a complete replacement review afterwards.
If there are unsaved practice changes, the replacement controls may ask whether to discard them. Save or download a draft if you need to retain the exercise. Saving a sample does not turn it into a real invoice, and loading an older saved sample can bring back fictional information you previously removed from the open tab.
Replace identities before amounts
Start with the seller and buyer names, addresses, countries, identifiers and contact details. Check that an example email has not remained after the visible company name changes. An invoice can look correct at a glance while its detailed party information still refers to the demonstration business.
Next replace the invoice number, buyer reference and dates. The sample’s payment reference may repeat its original invoice number, so inspect that separately. If you only replace the top-level reference, the payment section can still ask the recipient to quote the old sample number. This is a consistency problem even though each field contains readable text.
The sample country and currency also need an explicit decision. Do not keep EUR merely because the example uses it if your agreement is in GBP. Selecting GBP changes the currency label; it does not convert the sample prices into pounds. Replace prices using your actual agreement rather than calculating an exchange rate from invented amounts.
Rebuild the supplied items
Review every sample line. If an example has a workshop and consultation but you supplied equipment, replace both descriptions and the quantities and units behind them. Renaming a workshop as “chairs” while leaving its unit as “day” produces an internally confusing line.
A fictional photographer replacing two sample services might need one line for four editing hours and another for a fixed delivery package. The source contract should establish the description, unit, quantity and price of each. The sample’s existing number of lines should not determine how the actual work is grouped.
Tax values require the same discipline. Demonstration percentages illustrate arithmetic, not national tax advice. Enter the treatment confirmed for the real transaction, including a reason where appropriate. If the required treatment cannot be represented by the available fields, preserve the facts and use supporting software instead of imitating the sample’s simpler scenario.
Inspect the fields people overlook
Read the payment instructions in full. The production sample explicitly uses example account wording, which must not be presented as real instructions. Replace it with verified payment details or omit instructions that are genuinely unnecessary. Never substitute bank information taken from an unverified message just because it arrived while you were editing.
Read the notes after reviewing the main body. Notes can contain example-only explanations, an old customer greeting or a statement about illustrative taxes. Replace these deliberately, without deleting important limitations from your own understanding of the product. A clean-looking invoice still needs a suitable output format for its recipient.
Use the manual-review responsibilities to separate what a field check can detect from what only your records can confirm. A validation pass will not identify a fictional company name if the name is simply non-empty.
Check both the preview and the exported file
Read the preview from top to bottom, then inspect the output you intend to share. Search for memorable sample fragments, such as the example company, original invoice reference or demonstration account wording. Do this in application JSON as well as the visible document when that file is part of your workflow; a familiar cover view does not guarantee all stored fields were replaced.
Keep practice downloads in a separate location from real billing records. Give the reviewed export a clear filename and confirm that you are attaching that file rather than an earlier sample. This final selection check matters because the browser may retain several downloads with similar names.
The current product checks application fields and exports printable output, its own JSON and line-items CSV. It does not perform recognised-format validation. Replacing every fictional value makes the data yours; it does not by itself make the result XRechnung, Factur-X or another supported standard.