Can This ERP Handle Invoice Numbering Properly? A Practical Evaluation Checklist

Why invoice numbering deserves a workflow test

A demo that creates one invoice proves very little about how an ERP handles numbering over time. The more useful question is what happens when a transaction is saved as a draft, issued, cancelled, corrected, imported, or handled by someone with different permissions.

Treat numbering as a workflow to evaluate, not as a single setting to inspect. The checklist below is a way to structure demonstrations and sandbox tests; it does not assert that any particular ERP supports a given behavior. Ask the vendor to show each result in the product and document any limitations.

Keep two evaluations distinct. First, assess operational controls: what the application does and what users can see or change. Separately, confirm whether your intended process meets the rules that apply in each jurisdiction where you invoice.

• Use a test environment and sample records, not live customer invoices.
• Write down expected outcomes before the demonstration so you can compare the system’s behavior with your own process.
• Record which results were demonstrated, which were described but not shown, and which remain unanswered.

Map the documents and sequences your business uses

Before comparing systems, list the documents your business creates and decide which ones need separate sequences under your process. Do not assume that every document called an invoice, adjustment, or credit note must share—or must not share—a sequence. Define the business need first, then confirm any applicable local requirements with authoritative sources.

For each document type, capture who creates it, when it becomes final in your workflow, which entity or business unit issues it, and what happens when it needs correction. This inventory gives the vendor a concrete scenario to configure and demonstrate.

• List document types, such as customer invoices, credit notes, and any correction or cancellation documents your process uses.
• Record the relevant legal entity, business unit, sales channel, or other grouping, if your business needs numbering separated by one of these.
• Note whether your process needs a sequence to continue across a fiscal-period boundary or be configured differently at that point.
• Identify integrations, recurring transactions, imports, and manual entry paths that may create documents.
• Mark assumptions that require confirmation by a local tax authority or qualified adviser.

Test drafts, issued invoices, voids, and cancellations

Ask the vendor to demonstrate the whole lifecycle, not just the moment a number appears. Use a sequence of test transactions and observe what the system displays after each action. The goal is to understand the product’s behavior and whether your team can explain the record later.

Test both ordinary and exceptional paths. For example, create a draft and leave it unissued; issue another document; then cancel or void a test document using the workflow the system provides. Ask whether a later document receives a new number and what record remains for the earlier one. Do not assume the answer is the same across products or configurations.

• Does a draft receive a number, or only a document that reaches a specified status?
• Can users edit or discard a draft, and can you distinguish that action from cancelling an issued document?
• What number and status remain visible after a cancellation or void?
• Can the system explain an apparent gap in the sequence without silently reusing a number?
• Can the vendor show the underlying document history and describe which actions users may take?

Check credit notes, corrections, and reissued documents

Create a test case in which an issued invoice needs an adjustment. Ask the vendor to show how the adjustment is recorded and how a user can find the document it relates to. Then test a separate case where a document must be corrected or reissued under your process.

The important evaluation points are traceability and clarity: can a reviewer distinguish the original document from its later adjustment, and can your team explain what happened without relying on informal notes? Have the vendor show the relevant screens, records, and exports rather than relying only on a verbal description.

• Can a user navigate from the credit note or correction to the original invoice and back?
• Does the system preserve a readable relationship between the records after the adjustment is posted?
• What happens if the original invoice was created through an import or integration?
• Can the vendor demonstrate the process for correcting a mistake without overwriting history?
• Confirm the required treatment of corrections and related documents with authoritative local guidance or a qualified adviser.

Verify who can change numbering settings and what is recorded

A sequence is only as governable as the controls around its configuration. Ask the vendor to identify which roles can set or change numbering options and to demonstrate what happens when an authorized user changes a setting.

Do not infer that an audit trail exists from the presence of user accounts or an activity screen. Ask to see the record of a sample change, including what information is captured and who can view it. If the application does not provide the history your process requires, record that as a gap to assess before adoption.

• Which roles can create, edit, or deactivate a numbering sequence?
• Can access be limited to specific administrators or finance roles?
• Does the system record changes to the configuration, and can you inspect an example?
• Can a regular invoice user alter a number after a document is issued?
• Who reviews configuration changes, and how will your team document that review?

Review imports, migrations, entities, and fiscal periods

Numbering behavior can be harder to evaluate when records arrive from outside the ordinary entry screen. Rehearse the migration or integration path with sample data before deciding how to cut over. Ask the vendor to explain which fields are retained, which are assigned by the ERP, and how imported records can be distinguished from new ones.

If your business operates multiple entities or needs different sequences for different workflows, test those cases explicitly. Also test the boundary you care about, such as a fiscal-period change. Do not rely on a generic statement that the application supports multiple entities or configurable sequences; ask for a demonstration using your proposed setup.

• Import a small sample containing existing invoice references and check how the system handles duplicates or missing values.
• Confirm how migrated documents are identified and whether original references remain available to users.
• Test the numbering setup for each entity or business unit in scope.
• Create test documents on both sides of a fiscal-period boundary if your process treats that boundary as significant.
• Include integrations and automated creation paths in testing; do not test only manual entry.

Inspect reports, exports, and document history

A numbering control is difficult to review if your team cannot retrieve the relevant records. Ask for a live demonstration of the reports and exports you would use to examine issued documents, cancellations, adjustments, and sequence history.

Check whether the output gives enough context for a reviewer to follow a document from creation through later changes. If an apparent gap or unusual record requires a separate screen, manual query, or support request, include that operational effort in your evaluation.

• Can you filter and export documents by date, status, entity, or document type where needed?
• Can the report distinguish drafts from issued or cancelled documents?
• Can users find related credit notes, corrections, or reissued documents from the relevant record?
• Can you retain and review the history of configuration changes, if the product records it?
• Save sample reports and exports, then ask the people who will review them whether the evidence is understandable.

Separate software controls from local invoicing rules

An ERP demonstration can show how a product is configured and how users interact with it. It cannot, by itself, establish that your chosen process satisfies the legal requirements that apply to your business. Those requirements vary by jurisdiction, and the supplied product information does not establish any jurisdiction-specific numbering rule.

Use authoritative local sources—such as the relevant tax authority or legislation—and consult a qualified adviser where appropriate. Confirm your obligations for each place and entity in scope before treating a software configuration as compliant. Keep the resulting requirement separate from the vendor’s statement about what its application can do.

• List the jurisdictions and legal entities covered by the proposed rollout.
• Find the applicable requirement in an official local source or confirm it with a qualified adviser.
• Translate confirmed requirements into testable scenarios for the vendor or implementation team.
• Keep written records of the source, decision, system configuration, and person responsible for approval.
• Revisit the assessment when your scope or operating process changes; do not assume one setup suits every jurisdiction.