Colaborador social vs component architecture: why your customer should own their signing certificate
When you integrate a VeriFactu or FacturaE provider as a colaborador social, your client's invoices are being signed with a certificate that doesn't belong to them. Most tech leads don't register this until after the integration is done.
The invisible problem
You're building an ERP, a TPV system, or a piece of accounting software. At some point you need to connect to AEAT for VeriFactu, or generate signed FacturaE XML for public sector clients. You pick a provider, integrate their API, sign the contracts, and ship. Done. Or so it seems.
What many tech leads don't stop to ask is: who is actually signing these invoices? More specifically: whose certificate is in the XMLDSig signature block that AEAT receives? Is it your client's certificate? Or is it the provider's?
In the dominant integration model used by most Spanish fiscal SaaS platforms, the colaborador social model, it's the provider's certificate. Your client never uploads a certificate. The SaaS signs everything on their behalf, using its own identity. AEAT sees the SaaS as the technical signer, not your client.
This is legal. AEAT permits it. But it has implications that many ERP builders haven't thought through, for their clients and for themselves.
The two architectures
Colaborador Social
The colaborador social is an entity authorized by AEAT to interact with its systems on behalf of third parties (businesses, autónomos) using the colaborador's own certificate. In practice, a SaaS provider registers as a colaborador social and uses a single certificate (or a small pool) to sign submissions for all of its customers.
From your integration perspective, this is simple: you send invoice data to the API, the API signs it and sends it to AEAT. You never deal with certificates at all. That simplicity is the model's main selling point.
Componente
In the component model, the API acts as a neutral processor. Your client uploads their own certificate (their empresa certificate from FNMT or an accredited CA). When an invoice needs to be signed, the API uses the client's certificate, not its own. AEAT receives a signature that cryptographically identifies the client as the signer.
From your integration perspective, this adds one step: onboarding each client involves uploading their certificate. In exchange, the chain of custody for the certificate stays with the client.
Implications for your client
Legal responsibility and the meaning of a digital signature
A digital signature in the context of FacturaE or VeriFactu is not a decorative token. It's a legally meaningful attestation: "this entity, identified by this certificate, is asserting the content of this document." When the colaborador social signs, that assertion is made using the SaaS's identity. Your client hasn't technically "signed" anything in the legal sense of the word.
In practice, AEAT accepts this arrangement because the colaborador social framework provides a legal accountability chain. But in an audit, the certificate in the signature trace is the SaaS's, not the client's. Whether that matters depends on the client's industry, their legal advisors, and the nature of the audit.
Provider dependency and certificate continuity
If the SaaS provider changes their certificate, renews it, or has it revoked, all client submissions are affected simultaneously. If the provider goes out of business or terminates the client relationship, the client loses their submission capability and has no certificate of their own to fall back on.
In the component model, the client's certificate belongs to them. They can take it to any compliant provider, or build their own submission layer.
Audit trail readability
When AEAT audits records for a specific issuer NIF, the records show the SaaS's certificate in the signature. A forensic examiner looking at the chain sees "SaaS Provider X signed all invoices for 50 clients." In the component model, they see "Client Y's own certificate signed Client Y's invoices": a cleaner, self-contained audit trail.
Implications for you as an ERP builder
Switching costs
If you integrate as a component with a SaaS colaborador social, your clients are implicitly locked to that SaaS's certificate. Switching providers doesn't just mean pointing a different API endpoint — it means coordinating the transition of the signing identity. For clients with long submission histories, this creates friction.
In the component model, switching providers requires reconfiguring an API endpoint and potentially re-uploading the same client certificate. The certificate is the core identity; it belongs to the client and travels with them.
A commercially differentiating argument
"Your signing certificate never leaves your control" is a strong statement to make to a CFO or a legal department evaluating your ERP. It's true, it's verifiable, and it places your product in a different category from solutions where a third party holds the signing identity.
This argument compounds when you serve clients in regulated sectors (financial services, healthcare, public contractors) where certificate custody is explicitly audited.
Your own liability posture
Operating as a colaborador social (or integrating through one) creates a contractual and operational responsibility for your platform's certificate management. If a signing certificate is compromised, the blast radius covers every client signed with it. In the component model, each client's certificate scope is limited to that client.
When each model makes sense
This isn't a binary "one model is always better" situation. Both models exist because they serve different markets.
Colaborador Social is a reasonable choice for a single autónomo who just wants invoices to land at AEAT without dealing with certificates, like a self-employed carpenter who uses a simple invoicing app. The simplicity tradeoff is worth it for this use case. Complexity for a one-person business is a real cost.
Component is the right architecture for ERPs serving multiple clients, for software sold to medium or large businesses, and for any context where the client has a legal or commercial reason to control their own signing identity. If you're building a vertical ERP for legal firms, healthcare providers, or public contractors, you should be asking your provider which model they use, and preferring the one that keeps the certificate where it belongs.
How Kreyo does it
Kreyo is built on the component model. Your clients upload their signing certificate once (encrypted in transit, stored encrypted at rest), and Kreyo uses it to sign VeriFactu submissions and FacturaE documents. Kreyo never signs anything on its own behalf. There is no Kreyo certificate in AEAT's records for your clients.
The same certificate works for both products. A client who uses Kreyo VeriFactu for real-time AEAT reporting and Kreyo FacturaE for public sector invoicing uploads their certificate once and it covers both flows.
If a client leaves, they take their certificate with them. If Kreyo changes its infrastructure, their certificate (and the audit trail it represents) is unaffected.