Incorrect identifiers, incomplete master data and undefined rejection workflows can turn structured invoicing into recurringIncorrect identifiers, incomplete master data and undefined correction workflows can turn structured electronic invoicing into recurring manual work.
Aeterna corrects preventable data problems, improves validation and establishes a controlled process for rejected invoices around the accounting or ERP software the company already uses.
THE INVOICE IS STRUCTURED.
THE EXCEPTION PROCESS IS NOT.
THE SITUATION
A Belgian company has connected its accounting or ERP software to Peppol and can send or receive structured electronic invoices.
The technical connection may already be active, but invoices still fail, are rejected or require repeated corrections.
The finance team may encounter situations such as:
- The recipient cannot be found on Peppol
- The customer or supplier identifier is incorrect
- Required invoice information is missing
- VAT or company details do not match
- The invoice fails technical validation
- The customer rejects the invoice after receiving it
- The rejection reason does not reach the correct employee
- A corrected invoice creates another duplicate or mismatch
- Accounting records still require manual reconciliation
Since 1 January 2026, structured electronic invoicing has been compulsory for almost all transactions within scope between Belgian enterprises liable to VAT. Peppol is the standard network used to exchange those invoices.
The company is connected.
The data and operational process surrounding the connection may still be incomplete.
WHY IT BECOMES A PROBLEM
Peppol transports structured information between business systems.
It does not automatically correct incomplete company records, inconsistent identifiers, missing customer references or unclear internal responsibilities.
When invoices are created from unreliable customer or supplier data, the same problems enter the electronic invoicing process.
A single rejected invoice may be easy to correct.
Repeated rejections create a wider operational problem:
- Finance employees investigate the same error several times
- Suppliers and customers exchange corrective emails
- Payment processing is delayed
- Duplicate invoices or credit notes become harder to reconcile
- Different document versions remain inside the accounting system
- Rejection reasons are handled inconsistently
- Employees continue sending PDFs as a parallel workaround
- Nobody takes responsibility for recurring data-quality problems
A rejection response indicates that something failed.
It does not decide who must correct the source information, how the invoice should be reissued or how the accounting records should be reconciled.
COMMON COMPLICATIONS
THE RECIPIENT CANNOT BE IDENTIFIED
The customer exists in the accounting system, but the company number, Peppol participant information or routing details are incomplete or incorrect.
REQUIRED INFORMATION IS MISSING
The invoice lacks a mandatory field, reference, date, currency, tax value or business identifier.
COMPANY DETAILS DO NOT MATCH
The invoice uses outdated or inconsistent company names, addresses, VAT numbers or enterprise information.
TOTALS DO NOT RECONCILE
Line amounts, discounts, allowances, taxes and final totals produce conflicting values.
THE DOCUMENT FAILS TECHNICAL VALIDATION
The invoice structure or one of its values does not meet the applicable structured-invoice validation requirements.
THE CUSTOMER REJECTS A DELIVERED INVOICE
The invoice reaches the buyer but is rejected because of a price, quantity, purchase-order reference, delivery detail or commercial disagreement.
THE REJECTION REASON IS NOT ACTIONABLE
A status reaches the software, but employees cannot determine which record should be corrected or who is responsible.
PDF AND EMAIL PROCESSES CONTINUE IN PARALLEL
Employees send the structured invoice through Peppol and also send another version by email, increasing the risk of duplicates and conflicting records.
NOBODY OWNS THE EXCEPTION
Finance detects the rejection, but the correction depends on sales, procurement, master-data maintenance or the software provider.
WHAT A BETTER PROCESS LOOKS LIKE
The company knows how invoice information is created, checked, transmitted, corrected and reconciled.
Before an invoice is sent, the relevant process verifies that:
- The customer or supplier is correctly identified
- Required company and VAT information is present
- Mandatory invoice references are complete
- The correct document type is being used
- Totals and tax values reconcile
- Customer-specific information is included
- The document has not already been issued
When an invoice is rejected:
- The rejection reason becomes visible
- The issue reaches the appropriate owner
- The underlying source record is corrected where necessary
- The document is reissued through a controlled process
- The original and corrected versions remain traceable
- The accounting entry is reconciled
- Repeated causes are identified instead of corrected indefinitely one by one
The result is not merely the ability to send an electronic invoice.
It is a repeatable operational process for preventing, correcting and reconciling invoice exceptions.
THE GOAL IS NOT TO HIDE REJECTIONS.
THE GOAL IS TO MAKE THEM PREVENTABLE, TRACEABLE AND ACTIONABLE.
WHAT AETERNA FIXES
Aeterna works on the operational data, software configuration and correction workflow surrounding the company’s existing Peppol connection.
Depending on the agreed scope, Aeterna can:
- Clean and standardise customer or supplier invoicing data
- Correct preventable identifier and routing problems
- Validate required master-data fields
- Configure available pre-send checks
- Align recurring customer-specific invoice requirements
- Separate technical failures from commercial rejections
- Improve how rejection reasons are captured and assigned
- Correct affected source records
- Define a controlled correction and resubmission process
- Prevent avoidable duplicate documents
- Test representative invoice and credit-note scenarios
- Reconcile corrected documents with accounting records
- Coordinate software-specific changes with the accounting or Peppol provider
The objective is not to deliver a report explaining why invoices are rejected.
The objective is to correct preventable causes and leave rejected invoices moving through a clearer, repeatable process.
EXPECTED WORKING RESULT
Depending on the scope:
- Customer and supplier records contain more reliable invoicing information
- Preventable identification and validation errors are reduced
- Rejection reasons become easier to interpret and assign
- Employees know which source record must be corrected
- Corrected invoices remain connected to the original document
- Duplicate and parallel invoice versions are easier to prevent
- Accounting records are reconciled more consistently
- Recurring causes become visible instead of being repeatedly corrected in isolation
Aeterna does not promise that every invoice will always be accepted.
The working result is a more reliable invoicing process in which preventable failures are reduced and remaining exceptions can be traced and resolved.
OPERATIONAL VALUE
FEWER PREVENTABLE REJECTIONS
Incomplete identifiers, missing fields and inconsistent records are corrected before they repeatedly affect new invoices.
FASTER CORRECTION
Employees can identify what failed, who owns the issue and which source information requires correction.
LESS MANUAL FOLLOW-UP
Finance teams spend less time investigating the same failures through emails, telephone calls and disconnected software screens.
CLEANER CUSTOMER AND SUPPLIER DATA
The information used to create and route invoices becomes more consistent.
STRONGER TRACEABILITY
Original invoices, rejection responses, corrections and replacement documents remain connected.
BETTER ACCOUNTING RECONCILIATION
Corrected documents and accounting entries follow a more controlled process.
CLEARER COORDINATION
Finance, sales, procurement, accountants and software providers understand where their responsibilities begin and end.
WHAT THE BUSINESS RECEIVES
Depending on the agreed engagement, the business may receive:
- Corrected customer and supplier records
- Validated company and Peppol identifiers
- Configured pre-send checks where supported
- Corrected invoice requirements for recurring customer scenarios
- A visible classification of unresolved rejection causes
- A working correction and resubmission process
- Tested representative invoice scenarios
- Reconciled corrected documents
- Essential instructions for maintaining the process
Documentation is limited to what is necessary to operate, validate and maintain the corrected workflow.
SCOPE BOUNDARIES
Aeterna works around the company’s existing accounting software, ERP and Peppol provider.
Aeterna does not replace:
- The accountant
- The tax adviser
- The legal adviser
- The Peppol access-point provider
- The ERP or accounting-software specialist
The company and its qualified advisers remain responsible for confirming:
- VAT treatment
- Tax calculations
- Legal invoice requirements
- Commercial disputes
- Contractual prices and quantities
- Credit-note requirements
- Accounting treatment
- Decisions that require professional judgement
Platform-specific development, access-point configuration and technical changes requiring specialist credentials remain with the appropriate provider.
Critical changes are carried out only with suitable access, backups and validation.
RELATED SERVICE
PEPPOL DATA & INVOICE WORKFLOW OPTIMIZATION
A hands-on engagement for correcting recurring data problems, validation failures and rejection workflows surrounding structured B2B invoicing.
Suitable for:
- Belgian businesses receiving recurring Peppol rejections
- Finance teams correcting invoice data manually
- Companies moving away from PDF and email invoicing
- Businesses with incomplete customer or supplier records
- ERP and accounting environments connected to Peppol
- Companies with customer-specific invoice requirements
- Accountants supporting several business clients
- Software partners requiring operational data preparation
[DISCUSS YOUR PEPPOL INVOICE PROBLEM →]
RELATED USE CASES
Preparing customer and supplier data before an ERP or accounting-system migration:
[EXPLORE THE ERP MIGRATION USE CASE →]
Correcting customer prices and commercial rules between an ERP and a B2B portal:
