Skip to content
OpenPay
All articles

The qualified certificate, the SPV, and giving an app access to e-Factura

Romanian companies communicate with ANAF exclusively through the SPV, which requires a qualified digital certificate issued to a person holding rights over the company. It is registered with a confirmation document and form 150, and an application is granted access over OAuth 2.0: the certificate authorises once, the application receives a time-limited token, and the access can be revoked.

SetupThe OpenPay teamPublished 6 min read

Every conversation about automating invoices in Romania arrives at the same sentence, usually with an edge of suspicion: "so I have to give you access to ANAF?"

It is the right question, asked in slightly the wrong shape. Nothing reaches your ANAF data without an authorisation that you give, at ANAF, with a credential that is yours. The credential is a qualified digital certificate, the authorisation is recorded against your company, and both of them are things you can withdraw.

What follows is what that credential is, how it gets registered, what an application actually receives when you connect one, and the four ways companies break this for themselves.

The SPV is not optional, so the certificate is not either

Since March 2022, companies, sole traders and other entities without legal personality communicate with the tax authority exclusively through the Virtual Private Space. Documents handed in on paper are not considered submitted, and that rule — in the Fiscal Procedure Code — is what makes the rest of this unavoidable rather than a matter of preference.

The SPV is free and enrolment is handled by ANAF. For a company, acting in it requires a qualified digital certificate held by a person who has a right over that company. There is no username-and-password path for a legal entity, and no way to file or receive e-Factura without one.

What a qualified certificate is, and what it is not

A qualified digital certificate is an identity credential issued by a supervised trust service provider, held on a physical token or in a provider's secure environment, and protected by a PIN that only the holder knows. In law it carries the weight of a handwritten signature.

Three things it is not:

  • It is not a company credential. It is issued to a named person. The company appears on it, but the holder is an individual, and every action taken with it is attributable to that individual.
  • It is not permanent. Certificates are issued for a fixed term and have to be renewed. A certificate that expires quietly takes filing, e-Factura and anything connected to it down with it, on the day it expires.
  • It is not a password you can hand over. Sharing the token and PIN with a colleague or a provider is not a shortcut — it transfers a legal signature, and it is the single worst arrangement in this article.

Registering it with ANAF: the confirmation document, then form 150

Buying a certificate does not give you access to anything at ANAF. It has to be registered, and the sequence has two halves that people routinely do out of order.

Step Who does it What comes out
1. Obtain the certificate A qualified trust service provider The certificate and its token or PIN
2. Confirmation document You sign it with the certificate; the provider countersigns it An electronic document tying the certificate to your identity as ANAF requires
3. Form 150 — request to use a qualified digital certificate You, submitted to ANAF The registration request, with the confirmation document attached
4. Verification ANAF, with the issuing provider Confirmation of the right to file, by email to the address in form 150

ANAF's own guidance for filing with a digital certificate walks through the confirmation document in detail. The step worth not improvising is the authorisation: if the certificate holder is not the legal representative — an accountant, for instance — the company has to have empowered that person to sign on its behalf, and ANAF checks it.

Allow a few working days between submitting and being able to file. It is not instantaneous, and finance teams discover this on the 24th.

Who can act for the company

Three kinds of right exist over a company's space, and the distinction matters when someone leaves:

  • Legal representative — the administrator, as recorded in the company registry.
  • Designated representative — a person nominated by the company to act in the SPV.
  • Authorised agent (împuternicit) — typically the accountant or an accounting firm, acting under a mandate, usually with a narrower scope.

Two rules that save trouble later: give an external accountant an agent's rights rather than a representative's, and make sure at least one certificate with a representative's rights is held by someone who is not going to change jobs without telling you.

What an application actually gets

ANAF exposes e-Factura through an API, and access to it is granted with OAuth 2.0 — the same pattern as "sign in with" elsewhere, with the certificate playing the part of the login. ANAF publishes the procedure for registering an application.

What that means in practice:

  • The certificate is used to authorise, once. The application never holds your token or your PIN. You present the certificate at ANAF, ANAF issues an access token to the application, and from then on the application talks to ANAF with the token.
  • The access is scoped to the entities that certificate is enrolled for. If you hold rights for three companies, the authorisation can cover them; if you hold rights for one, it covers one.
  • The token is time-limited and has to be renewed. This is a feature, not a nuisance: an authorisation nobody renews expires on its own.
  • You can revoke. Access ends when you end it, on your side, without the application's cooperation.

The important sentence for anyone weighing this up: an application with API access can read the documents your company sends and receives through the system it was authorised for. It cannot move money. Payment is an entirely separate authorisation, at your bank, described in how open banking actually works.

The four ways this breaks

Nearly every "our e-Factura stopped working" story is one of these:

  1. The certificate expired and nobody owned the renewal. Put the expiry date in the same place as the insurance renewals, not in one person's inbox.
  2. The only holder left the company. If the sole certificate with rights over the company walks out of the door, the company is locked out of its own tax correspondence until a new registration completes.
  3. Everything runs on the accountant's certificate. Convenient, until you change accountants, and legally awkward long before that.
  4. The token is shared. Every filing, and every payment that follows from one, is attributable to the named holder. Sharing it destroys the one thing the certificate exists to produce.

Where OpenPay fits

OpenPay connects to ANAF the ordinary way: you authorise access from inside your account, using your own certificate, and the authorisation is recorded at ANAF against your company. From then on your supplier invoices arrive on their own — see paying the invoices ANAF delivers for what happens next. Tax obligations are not part of that access; paying taxes to ANAF covers those separately. You can withdraw the access at any time, from the same place you granted it, and paying is a separate authorisation that happens at your bank with multi-factor authentication.

Sources

General information, current at the date of publication — not tax or legal advice. Check your own situation with your accountant before acting on it.

Close the tabs. Keep the list.

Connect ANAF and your bank, and see your next payment run in one list.