Check an invoice creator’s actual output documentation against your recipient’s named requirement. Look for the format, supported profile and version, validation performed and any delivery integration. A product name containing “e-invoice”, a professional preview or an XML download button is not enough evidence that the exact workflow you need is implemented.
Start with a written recipient instruction, not a general feature comparison. The first-invoice workflow places this check before final preparation, because discovering an unsupported format after entering a long invoice can create avoidable rework. This article concerns capability verification, rather than deciding which standard a customer should adopt.
Turn the requirement into a short test
Write down what the customer actually requested. Separate the document format from its profile, version and submission route. Include mandatory references or identifiers the customer names. A requirement record such as “structured format confirmed; buyer reference required; portal submission” is more actionable than “needs electronic billing”.
Ask the software provider which parts of that requirement it implements. Does it generate the relevant document, merely prepare source data, or rely on a separate integration? If the answer refers to a future roadmap, treat the function as unavailable until it is released and its behaviour can be checked.
Do not assume that a country selector applies the country’s rules. It may only record an address or context. Similarly, a payment-method selection may label instructions without processing payments, and an account screen may store drafts without creating an issued-invoice ledger.
Inspect an actual output, not only a screenshot
Use fictional test data to obtain a sample file if the product offers a safe demonstration. Inspect the file type and its declared structure. A JSON file may be an application backup rather than a recognised invoice representation. A CSV may contain item rows but omit the supplier and buyer record entirely.
A readable PDF can be appropriate for a recipient requesting a visual document. It does not automatically contain embedded structured data. If a provider claims a hybrid invoice, identify the relevant specification and checks rather than assuming that any attachment inside a PDF is sufficient.
Check what happens with a slightly more realistic transaction: a second line, a fractional quantity, a discount and a buyer reference. Simple demonstrations can hide missing fields or adjustments. Use illustrative tax data only for arithmetic testing, not as evidence that the software has determined the right treatment for an actual business.
Ask what validation means
A required-field checker and a standards validator answer different questions. Ask which rule set and version are applied, whether the final exported file is checked and how errors are reported. A statement that “all fields are complete” does not establish conformance to a semantic model or recipient profile.
Consider a fictional customer requiring a structured buyer reference. A preview may print that reference in notes while the export leaves the intended field empty. A human screenshot review can miss the mapping problem. A validation report should be interpreted alongside the specification and the actual file.
Where independent validation is part of your workflow, retain its report with the tested version. Do not substitute the product’s marketing badge for evidence of what was checked. A successful check still does not prove every business fact or guarantee recipient acceptance.
Check the boundaries of delivery and storage
Ask whether the creator sends files or simply downloads them. If a service connects to a network or platform, establish what is required to activate it and which acknowledgement it provides. A local export should not be presented as a submitted or delivered invoice.
Understand how drafts are stored. A browser-local save is different from a secure account-based history available across devices. Check whether saving is explicit or automatic, whether later edits are preserved and what deleting a draft actually removes. These details affect the reliability of your preparation process even when the export format is suitable.
Also check where entered data is processed. If invoice content is uploaded or sent to an AI service, the product should explain that processing clearly. Do not use real customer data merely to discover how a demonstration works.
Apply the test to EInvoiceCreator
The current product provides a live readable preview, ordinary positive invoice calculations, application field validation, explicit local draft saving and editable JSON import. Its outputs are printable invoices, application-owned JSON and line-items CSV. Browser Save as PDF depends on the browser’s print capability.
It does not generate or formally validate EN 16931, XRechnung, ZUGFeRD, Factur-X or Peppol documents. It has no routing, government submission, payment processing or account-based invoice history. Its country context does not apply a national profile, and its tax entries do not determine legal treatment.
When those capabilities fit the preparation stage, use the tool honestly for that stage. If the recipient needs more, preserve the source details for appropriate supporting software. The creation, validation and delivery distinction helps describe the remaining work without confusing preparation with completion.
Record a clear capability decision
Write down which requirement is supported, which is external and which remains unresolved. A limitation can be acceptable when the next stage is planned and verified. The practical risk comes from assuming that a named format, country or network is implemented when only an educational page or planned feature mentions it.
Recheck this decision after meaningful product changes or recipient updates. Keep the tested output and relevant instructions so future invoices do not depend on someone’s memory of what the tool appeared to support.