In the 4-corner model, business-level response messages, such as invoice responses, are sent from Corner 4, the recipient of a document, to Corner 1, the sender of a document, as a response to that document. In the case of invoices, such messages can carry information about, among other statuses, that the invoice has successfully arrived, and whether it is accepted or rejected. Other examples of business-level responses are Order Response, but I’ll focus on invoice responses in the rest of this article.

Invoice responses are where the value of e-invoicing really starts to shine, compared to more traditional methods of sending invoices: your software could not only show whether the invoice actually arrived at the recipient, but also whether there are any issues with the invoice or that it has been accepted, or even paid.

Obviously, this only works if both the sender’s and the recipient’s end-user software actually implements support for invoice responses, but that is not what this article is about. This article discusses the challenges regarding their addressing. Or rather, regarding controlling the routing of such responses from the original sender’s end.

On the Peppol network, Invoice Responses are sent to the peppol identifier provided in the AccountingSupplierParty’s EndpointID. In a standard scenario, where a participant has a single service provider that they use for both sending and receiving, for all their documents, this works great; add Invoice Response (or any business-level response) capability to the existing SMP publication of the participant, and the recipient of the invoice can do the associated lookup, and send their response back to Corner 1.

However, there are a number of cases where the process isn’t quite so straightforward. For example: What if you have multiple service providers? What if you use a different service provider for sending than you do for receiving? What if you are the customer of some central platform, which sends invoices on your behalf, but only for the services you offer through that platform (so the platform only sends a subset of all your invoices, and you also have your own peppol connection)?

If you have a central ERP system, with multiple connections to the Peppol network, this doesn’t really matter: as long as the response arrives at the system that has knowledge of the original invoice, it can process the response. But in many of these scenarios these are different systems, and the response should be sent to a different location, depending on where it was actually sent from.

Some examples of such scenarios:

• A business has a different department responsible for purchases and sales, and those departments have different systems with their own connection to the Peppol network.

• A supplier may have different invoicing systems for different purposes. Perhaps because of an acquisition, but perhaps because they are active in sectors where completely different systems are better suited. The systems are not connected and responses should be addressed directly at those systems.

• An e-commerce platform provides shops the option of setting up a B2B store. The service includes automatic creation and sending of invoices for the suppliers that own a shop there (sending only). Those suppliers that use the platform may also have their own administrative systems, which may also have a connection to the network, for all their other business. Responses to the invoices sent from this platform should in this case be addressed so that they arrive at the platform, and not at the individual administrative system the suppliers may have.

Workarounds / solutions

Configuring on the SMP

There is one specific scenario that can be solved on the SMP itself: if a participants uses two service providers, where one is for sending and the other for receiving only, it’s just a question of configuring response messages correctly on the SMP (either directly or through a redirect). But this only works in that very specific scenario.

A central orchestrating receiver

In a number of scenarios, especially when it’s a (large) company that has multiple systems that process invoicing information, one could imagine a central system where all documents arrive. They are then internally routed to the correct final system. This works for large organizations that manage their own connection to the network, but quickly runs into practical problems in many other scenarios. In the platform scenario, this is simply not an option, unless the platform creates custom integrations with each and every of their customer’s systems.

Different identifiers for different purposes

An often used workaround is to simply use multiple identifiers. For instance, use your VAT number for receiving documents in general, but use a GLN as your identifier when sending one. The response will then be sent to your GLN, where standard invoices are sent to your VAT number.

Some countries have multiple schemes that one can use, which makes this scenario slightly easier, but it does not really scale well; you’ll need a separate identifier for every connection to the network that you have.

Another issue with this approach is that it requires a relatively high amount of control from the end-user itself: They will need to manage which identifiers they have, and which they use for what services.

In the platform case, it does not need separate identifiers for all its supplier users; the platform could set the Supplier EndpointID to an identifier belonging to the platform itself, thereby needing only a single separate identifier for all its users. This has drawbacks too: if the recipient shows the sending endpointID, it will be the platform’s, and not that of the party whose name is on the invoice (also present as PartyLegalEntity). The platform will also need to make sure all invoice numbers are unique, as the supplier’s identifier will not be present in the response.

Expanding the envelope

The Standard Business Document Header (SBDH) is added to all documents exchanged on the network, and contains, among other data field, the sender’s and recipient’s peppol identifier.

One proposal that has been offered is to expand this with a ‘Reply-to’ field, where business-level responses are supposed to be sent.

This requires a change in the envelope, but it does offer much flexibility: whoever created the envelope can determine where responses are supposed to be sent. There is also a precedent in the Message Level Status (MLS) specification: MLS added an MLS_TO to the envelope, to determine the service provider where the MLS should be sent.

However, it also has some drawbacks:

Essentially, this moves the EndpointID semantics from the payload to the envelope, so the system that creates the response (at Corner 4) must have access to the information in the envelope. It’s currently far from usual to pass the entire envelope on to the recipient. If it isn’t passed on, Corner 3 must offer a way for Corner 4 to create the correct response, which includes retaining the envelope data until the entire process is complete, which has no set time limits.

Also, there must still be some identifier available to use there. In the case of the platform, that is relatively easy. But in other cases the end user must still have a separate identifier available for each separate system that needs to be sent specific responses.

Perhaps a suffix for EndpointID?

Yet another approach could be to add an (optional) suffix to identifiers. The main ‘standard receiving’ identifier would still be the usual VAT or Chamber of Commerce number, but for specific sending scenarios, the sender could add a scenario-specific suffix.

For example, suppose one uses an identifier 0301:111222333 according to the hypothetical scheme 0301. This is still the main ‘recipient’ identifier that is published to receive invoices. For sending invoices through a second system with a second service providers, they would still use 0301:111222333 as their PartyLegalEntity/CompanyID, but as the Suppliers EndpointID, they’d use a suffix identifier 0301:111222333#2. (Note: I chose # as a separator here, specifically because it’s currently not allowed as a character in peppol identifiers).

Another example is a platform called FORMPLATZ, that would add the suffix #FORMPLATZ to all the EndpointIDs of their outgoing invoices. In this example that would create the sender identifier 0301:111222333#FORMPLATZ for invoices sent from FORMPLATZ on behalf of 111222333.

This identifier is published in an SMP separately, with only support for the relevant response document type.

This also offers flexibility, is not limited to whatever identifier schemes the end user has available, and the original ‘real’ identifier can still be deduced from the identifier, even if the actual sending party is a platform.

Of course, this is not without drawbacks either: it redefines the format of all identifiers used in EndpointID, and therefore likely requires a new identifier scheme other than iso6523-actorid-upis. And given how standard iso6523-actorid-upis is, I’m far from sure how many systems have this value hardcoded.

Conclusion

Essentially, the fundamental problem is that we’re conflating identification with addressing (and thereby with routing), by using a peppol identifier, which is based on identity, as the address, and not leaving room for additional addressing/routing signals. This forces participants to manage multiple identities if they need to convey different addressing requirements.

Secondly, since we’re putting the main metadata in the invoice payload itself (through the mandatory EndpointID, technically a layer violation in and of itself), it’s not common to pass the full metadata (the SBDH) on to the system that needs it; the system creating the response.

Using different identifiers is a workaround that has been successfully applied, but is also very limited. I’ve described two other potential approaches, both of which have problems of their own.

There may be other approaches as well, or solutions to the problems that I have not thought of. But given the potential that full invoice response support gives in terms of user experience, I think it’s well worth the time and effort to work on an approach that works across the entire chain, in many different scenarios.