Once you have decided that you will use invoice data as a data asset, the following questions will arise:
1. Do you want to use only invoice data generated by 3rd party software, or do you want to provide an online invoicing service, too?
2. What capabilities do you need to start with a digital invoice management solution?
3. What is the rationale to start online invoicing in-house or provide the invoicing service through partnerships?
4. What do you need to consider when starting an invoice-related service integrated into digital banking channels?
5. How can invoice data related services be defined for the different segments?
Use or generate invoice data?
From the previous articles it is inevitable that invoice data is a strategic data asset for banks, the only question is, whether to use the data or engage in providing services related to invoice data?
Although we are focusing on the SME segment now, it should not be forgotten that services related to invoice data can be offered to the corporate and retail segments, and the use cases are interconnected with each other, as when we are talking about invoicing, there is always a sender and a receiver of an invoice. Corporates and SMEs can be both invoice senders and receivers, while retail customers are always on the receiver side. So, if the bank provides an invoice-related service for SMEs, with the same capabilities and incremental resources the service can be extended to other segments as well.
In the next section an analysis can be found about the capabilities required for the bank to manage invoice data and to provide invoice-related services for the different segments.
The bank does not provide an invoice-related service, only uses third party invoice data
If the bank does not provide invoice related services, but wants to use invoice data for the digitalization of its own processes and for data analysis, it will still need the following capabilities to efficiently work with structured invoice data:
Knowledge of invoice data fields
The bank will need to be familiar with the invoice document and the various data fields an invoice can contain. This is important, because the bank will need to select, which invoice data fields should be used by the bank.
Working with structured e-invoice data
In many jurisdictions the required format is a hybrid e-invoice format, which means that the structured invoice data in xml format is embedded into the invoice pdf. This makes the structured invoice data automatically processable.
In other cases, invoice data is only produced in data format. In this case the invoice data is only machine processable but is not in a readable format for the human eye.
Standardising invoice data structures
Despite the standardisation efforts of the e-invoicing regulations, there are and there will be various invoice data structures. If the bank wants to efficiently work with invoice data, then it will need to have capabilities for data transformation and standardisation of the various invoice data structures. These capabilities are necessary, because the bank will need to transform various invoice data formats into a standardised format, and this standardised data format will need to be transformed to data structures required by the specific use cases.
There will be local invoice data standards required by e-invoicing regulations, which the bank can use. However, if the bank deals with invoices from more than one specific geography, which is most likely the case, because customers will have cross-border transactions, hence invoices will have different formats, the best solution is to choose a widely used global standard. Currently, most legislations use the OASIS UBL standard as the starting point for the localisation of the standard invoice format.
Processing various invoice formats
If e-invoicing or continuous transaction controls are already implemented in a country, then these regulations require invoice data to be produced by systems in the local standard. In these cases, the local standards can be used and configured for structured data processing.
This principle is true for all local tax regulations. This means that if foreign invoice data is available in a structured format, then they can be processed automatically, if the receiver system is configured to process these, too.
There can be cases, when the local standard does not require all invoice data – in these cases the richest available data source should be used for invoice processing. For example, if the tax authority requires only data for the supplier, buyer, invoice items and invoice dates, but not data related for payment, but the source system provides all invoice data, then the primary data source should be the source system, and the tax authority system can be used for cross-checking the data and authenticity of the invoice. However, if the source system is not accessible, but data is available from the tax authority then the data from the tax authority should be used.
Working with invoice data from 3rd party data sources, integration capabilities
If invoice data is generated in 3rd party applications, then the bank must have efficient data exchange/integration capabilities, to get hold of invoice data.
3rd party data sources can be online invoicing systems, accounting systems or ERP systems or tax authority interfaces. From these data sources invoice data can be made accessible via API integrations. If these systems do not produce hybrid e-invoices (or invoice data files), then the best way is to directly integrate with these systems to get access to the invoice data produced by them.
Management of supplier invoices
The above principles and mechanisms can be applied both for customer and supplier invoice data. In case of supplier invoice data, the source will always be either structured data or hybrid invoices or tax authority information.
Only in certain cases will be integration present, when the bank is already an integrated with the system, from which the seller provides the invoice data.
There is a special case, when the supplier produces its invoices in the same system as the buyer – for example when both the buyer and seller use the same invoicing platform.
The bank provides an invoice-related service
If the bank chooses to provide invoice related services for customers, in addition to the above capabilities, i.e., Knowledge of invoice data fields, Standardising invoice data structures and Integration capabilities the below capabilities are required:
Presentation of invoice data
If the bank provides an invoice management service for its customers, then it will need to present the invoice data. This will include the presentation of:
- individual invoices, including:
-invoice images and
-invoice data - invoice lists, which will present specific invoice data.
Data transformations
Data transformation capabilities are important to utilise the value of invoice data to standardise different invoice format and generate payment instructions, payment requests or financing requests from invoice data.
Messaging
Invoices must be sent and received; therefore, the messaging capability is a must for an invoice management solution. Messaging includes the addressing mechanisms and dealing with centralised or decentralised address books. A centralised address book is for example a global invoicing address book for all entities in each country. Such address book is used in Switzerland or will be used in France. A decentralised address book is kept for example at Peppol, where specific service providers keep their local address books, and the invoicing addresses can be inquired from them by other service providers to reach their invoice addressees. In this case there is not one global address book containing all company addresses, but several local address books are kept.
Managing e-signatures
Integration with e-signature service providers and checking the authenticity of e-signatures is also a required capability, as applying e-signatures is a common way to ensure that the invoice is authentic, and the invoice content is not corrupted. In certain legislations it is mandatory, while in others it is only recommended or not required at all.
Knowledge of invoicing as a domain and keep track of invoicing rules
If the bank starts its own online invoicing service, then it must acquire knowledge about invoicing as a domain. This means understanding the following:
- invoice as a document,
- general invoicing and local taxation rules,
- mandatory features for an online invoicing solution,
- design principles of an online invoicing solution.
The above are important, because the customer journeys and technical solutions designed by the bank must consider the above, so that the solution is tax compliant and is easy to use for the customer.
If the bank decides to start its own online invoicing solution, then it must keep its invoicing solution always up to date with the changes in accounting and taxation rules.
