Receiving an e-invoice is not the same as keeping it. The reform made everyone think about sending and receiving. Retention is a separate obligation, it lasts longer, and most companies have not yet decided who handles it. PSE Connect keeps the invoice in a form that cannot be altered, for the ten years the law requires.
The obligation
| Requirement | Source | Duration |
|---|---|---|
| Keep invoices for tax purposes | Article L102 B, Livre des procédures fiscales | 6 years |
| Keep accounting records | Article L123-22, Code de commerce | 10 years |
| Preserve authenticity, integrity and legibility | Article 289 VII, CGI | the whole period |
| Keep them in their original electronic format | BOI-CF-COM-10-10-30-10 | at least the audit period |
Two consequences that catch people out. A PDF copy is not compliance: the law asks for the invoice in the format it was received, which for a PEPPOL invoice is the UBL XML and not a printout. And the platform is not the archive: an approved platform keeps documents only for the period tied to its own mission, so ten years later it will not have your invoices.
Does the archive have to be on an approved platform, a plateforme agréée or PDP?
No. Archiving is not among the mandatory functions of an approved platform. The DGFiP defines four: issuing, transmitting and receiving invoices, and sending invoice, transaction and payment data to the tax authority. Retention is not one of them.
The obligation stays with the company, which can archive in-house, with its software vendor, with a third-party archiver, or through a service like this one. No certification is legally required.
What PSE Connect does
Every invoice received through PSE Connect is written a second time into write-once storage, as three objects.
invoice.xmlThe PEPPOL UBL exactly as received, byte for byte, never transformed.
invoice.pdfThe readable document.
manifest.jsonWho sent it, on which PEPPOL endpoint, to whom, the invoice number, date, currency, total and VAT number, with a SHA-256 fingerprint of each file.
It cannot be altered or deleted
Retention is enforced by the storage platform itself, not by our software. Once written, the file is locked for ten years. We tested it by trying to delete an archived invoice, and the platform refused.
Its integrity is provable
Each file carries a cryptographic fingerprint. Re-reading the file and recomputing the fingerprint shows whether a single byte has changed.
Its history is recorded
Once a month closes, each legal entity gets a sealed journal listing every invoice archived in that period with its fingerprints, plus the fingerprint of the previous journal. Remove or alter anything and the chain breaks visibly from that month onward. A month with no invoices has no journal and the chain simply links past it, so a quiet month is not a gap. This is the lifecycle journal that NF Z42-013 expects.
Its dates can be proven by a third party
Each monthly journal is timestamped by an independent Time Stamping Authority. Only the fingerprint leaves the building, so the authority never sees an invoice. With a qualified provider under eIDAS the timestamp carries a legal presumption: it is then for a challenger to show the date is wrong, rather than for you to show it is right.
Separation
One sealed container per legal entity
Retention, legal hold and export are all per entity, which is how the tax authority looks at a group and how a customer who leaves expects their data to be handed back. For a group across several countries that means one platform with clean separation rather than one shared bucket and an explanation.
Restitution
Getting it back out, without asking us
A period can be exported as one package holding the invoices as archived, their manifests, the monthly journals, the timestamp tokens, a report of every check made at the moment of export, and written instructions for repeating all of it with sha256sum and openssl alone. Nothing in it depends on PSE, which is what makes it an exit and not a favour. If a document ever failed its check it would be in the package too, named and reported, rather than quietly left out.
Since September 2026 this is a screen in the application rather than a request to us. See the Archive tab below.
The Archive tab
Added in September 2026, and the answer to the question every finance team eventually asks: my auditor wants the invoices, how do I give them to him?
It reads the sealed store, not the server
This matters more than it sounds. The working copy on the application server is exactly the file an auditor is asking you to prove you did not alter, so handing that one over proves nothing. Every figure and every byte on this tab is fetched back out of the immutable container and its fingerprint recomputed on the way.
What it shows
Per legal entity: how many invoices are archived and how many are not yet, the months that exist, and whether the container carries its immutability policy. Each closed month can be verified on the spot, which walks the journals backwards and re-checks that each one still points at the month before.
The month in progress is never sealed
A journal describes a complete month and cannot be rewritten afterwards, so sealing one early would record something untrue for ten years. The current month is shown as open and is sealed when it ends. The tab says so rather than leaving a gap for someone to misread.
It is read only
There is no delete and no purge on this tab, by construction rather than by hiding a button. That is what makes it safe to give to somebody from outside the company. Purging, which is irreversible, stays where it was, behind a separate right.
So how does the auditor actually get the invoices?
Today, the customer opens the Archive tab, chooses the months and downloads the export package, then hands it over. No account is created for the auditor and no credential is issued.
That is deliberate rather than a limitation. The package is self-verifying: the auditor checks the fingerprints and the timestamp tokens with standard tools, without PSE and without having to trust us. That is stronger evidence than being given a login, and nothing stays open once the audit is finished.
On screen
September shows as open rather than as a gap or an error. A journal describes a complete month and can never be rewritten, so the month in progress is sealed only once it ends. Saying so on the screen is deliberate: an auditor who sees an unsealed month and is not told why will assume the worst.
Sending it to the auditor
The problem it solves
A package is not an e-mail attachment
A year of invoices is hundreds of megabytes. It does not travel by e-mail, and putting it on a file sharing service moves the problem rather than solving it. The alternative, creating a login for the auditor, means a credential on somebody else's laptop for as long as anyone forgets to remove it.
How it works
A link that expires by itself
The customer chooses the months, how long the link should live and how many downloads it allows, and optionally a passphrase given to the recipient by another channel. They get one URL to send. No account is created and nothing is provisioned.
The link can be withdrawn at any moment, every download is recorded with its date, and when the lifetime or the download count runs out it stops working and the package is deleted from disk. The record of who shared what, and who downloaded it, is kept: that is the audit trail of the audit.
What the auditor sees
The package in this example covers three months, of which the last was still running and therefore has no seal yet. The page carries a line saying so, just under the verification message, rather than leaving the auditor to count the seals and wonder. These screenshots were taken just before that line was added.
What we do not claim
Overclaiming is how a compliance conversation goes wrong. These are the limits, stated before anyone has to ask.
- We are not NF 461 certified. That certification applies to a third-party archiving operator and PSE is not one. We follow the principles of NF Z42-013 and ISO 14641. No certification is legally required, and we would rather say so than imply an accreditation we do not hold.
- We are not an approved platform for archiving. No such thing exists. Archiving sits outside the approved-platform mandate entirely.
- Timestamping is qualified only when contracted. The mechanism is live. Using a qualified eIDAS provider, which is what gives the legal presumption, requires a contract with that provider, so it is available as an option rather than something already in place.
- We do not verify the timestamp signatures ourselves. We store the full token so anyone can verify it with standard tools. That is deliberate: verification does not depend on PSE.
- This currently covers received invoices. Sales invoices sent through PSE Connect carry the same obligation and are the next step. They are not covered yet.
- Integrity is proven from the moment of archiving, not before. Invoices already held when the archive is switched on for a customer are archived at that point, and the manifest records the date received and the date archived separately rather than presenting one as the other. No archive can show that a document was never kept out of it in the first place, which is why the monthly journals list the documents rather than only counting them.
- A share link is an unauthenticated URL. Anyone holding it can download that package until it expires, which is why the lifetime is capped, the download count is limited, every access is logged, and the link can be withdrawn at once. We would rather state that plainly than describe it as secure and leave you to discover what it means.
- The Archive tab is an option, off by default. It is enabled per user by PSE, like the other Connect options. A user who does not have it sees no tab and the endpoints behind it refuse, and holding it never widens which documents that person can see: it opens a screen for their own legal entity, not anyone else's.
- PSE does not become the legally responsible party. The retention obligation stays with the company. We provide the means and the evidence, not the liability.
Sources
- Article L102 B, Livre des procédures fiscales
- Article L123-22, Code de commerce
- Article 289 VII, Code général des impôts
- BOI-CF-COM-10-10-30-10, délai et mode de conservation des documents
- Facturation électronique et plateformes agréées, impots.gouv.fr, for the four mandatory functions
- Règlement eIDAS (UE) 910/2014, article 41, qualified electronic timestamps
- NF Z42-013 and ISO 14641, probative electronic archiving
- The underlying storage is independently assessed against SEC 17a-4(f), CFTC 1.31(c)-(d) and FINRA 4511 for write-once retention
Why we ask
Every e-invoicing project looks the same on a slide and different in practice. These answers are what let us size the work honestly and come back with a scope and a price rather than a range.
They tell us three things in particular:
- Your volumes decide which Automation Studio licensing model is cheaper for you, connections or tasks
- Your Kinetic version and deployment decide how the Epicor function and the REST calls are set up
- Your countries and your deadline decide what has to be ready first, and whether an existing access point can be kept
Nothing here is binding, and a rough figure is more useful than a blank field.
One thing worth saying before you ask. French e-reporting, which covers B2B export and B2C invoices, needs recipes beyond the four in the base package and is not built today. The four cover AR B2B invoices and AP receipt, which is what every supported country runs. If your answers below include e-reporting, that is scope we size separately rather than something already in place.
A complete, packaged solution: Epicor standard objects, the automation that drives them, the services to put it in place, and optional cloud access to what the access point holds.
PSE_EINV_[COUNTRY]) holding AP, AR and the two connections, including the private connector to Storecove.Two delivery channels, one solution
Channel 1
Epicor Automation Studio
The straight-through layer. Automation Studio, powered by Workato, moves the document between Kinetic and the network with no interface at all, on a schedule the customer sets.
- Four base recipes per country project: three for AR, one for AP, plus the two connections
- The base AP recipe delivers the documents to an address you choose, and is then fine tuned during onboarding to follow the customer's own AP flow
- Built on the Epicor Kinetic connector, alongside Outlook, SharePoint and the other connectors a given flow needs
- The preparation step is an Epicor function, so the mapping follows the customer's own data model
- Job history is the diagnostic surface when a document is rejected
- Epicor sells Automation Studio two ways, mutually exclusive: one connection per endpoint, or a volume of tasks bought as packs of 100,000 a year
- PSE recommends the volume model, which is what most of our customers run: it leaves them free to connect as many endpoints as a flow needs. At high document volumes the connection model can work out cheaper, so both are worth pricing
Channel 2
PSE Connect — apps.pse.be
Storecove supplies the API and keeps each country's format compliant, and counts on partners to put that API inside the customer's process. PSE Connect is that layer, built so a customer who subscribes to Storecove can actually see their documents.
- Documents Sent: status, XML and PDF of every AR invoice on the network
- Documents Received: the full inbox, with any selection bundled as a ZIP to download or email
- Every invoice received is also written a second time into sealed, write-once storage, in the format it arrived in, for the ten years the law requires
- An Archive tab that reads that sealed store rather than the working copy: what is archived month by month, a seal check on demand, and the export package an auditor verifies without us. See the Archiving tab →
- Multi-tenant in production, each legal entity seeing only its own documents
- Five interface languages: EN, FR, NL, DE, ES
Most customers use both. Automation Studio removes the work nobody needs to look at; the portal gives the accountant somewhere to look when they do.
Where this runs today
| Country | Network model | Formats handled |
|---|---|---|
| Belgium | PEPPOL four-corner, Storecove as access point | PEPPOL BIS 3.0 UBL, PDF embedded in the UBL |
| France | Plateforme agréée, recipient resolved through the Annuaire | Factur-X, CII (CTC-FR extended), UBL |
One normalised document is sent to Storecove, which handles the country-specific conversion and routing. Adding Germany, Spain, Ireland, the Emirates or another country Storecove covers is therefore a configuration and testing exercise on a working pipeline rather than a second build, and PSE takes that on demand.
On the AR side everything currently targets Storecove: the recipes, the Epicor function and PSE Connect are all built for its API. Another access point is possible and the shape of the work does not change, but it is adaptation rather than configuration. On the AP side the same Automation Studio layer has already been pointed at Yooz, Pennylane and Zeendoc where a customer already had a platform in place.
Why the Kinetic side matters
The footprint is three screens
Customer, AR Invoice Entry and AR Invoice Tracker. One panel, one label, one checkbox and one status page. Every existing process around invoicing keeps working untouched.
The invoice stays the record
Status, evidence XML, document link and the activity log all live on the AR invoice. Credit control never leaves Kinetic to find out whether a customer received an invoice.
A rejection is readable
When the network refuses a document, the Automation Studio job shows where and why, and the same job is reprocessed once the cause is fixed. No reconstructing the story from a status code.