Archivado electrónico de facturas y documentos en C# con PDF/A para España

Plazos de conservación: LGT, LSC y sectoriales

Cuatro marcos operan en paralelo y un mismo documento puede caer bajo varios simultáneamente:

• Ley General Tributaria (LGT) — artículo 66: el plazo de prescripción de las obligaciones tributarias es de 4 años, contados desde el día siguiente al de finalización del plazo reglamentario para presentar la autoliquidación. Cualquier interrupción de la prescripción (notificación de actuación administrativa, recurso, reconocimiento de deuda) reinicia el cómputo. Para inversiones que generan derecho de deducción a lo largo de varios ejercicios, el plazo efectivo de conservación se extiende hasta 10 años o más. Las facturas emitidas y recibidas, los libros registro de IVA bajo SII, los modelos AEAT (303, 390, 347, 720, etc.) entran en este régimen.
• Código de Comercio + Ley de Sociedades de Capital (LSC) — artículo 30 CCom: los empresarios deben conservar libros, correspondencia, documentación y justificantes durante 6 años desde el último asiento. Este plazo es independiente del fiscal y aplica incluso si la actividad cesa.
• Sectorial regulado — banca y seguros bajo supervisión del Banco de España y la DGSFP aplican plazos más amplios (típicamente 10 años); sanidad bajo Ley 41/2002 de autonomía del paciente conserva la historia clínica 5 años desde la última asistencia (con excepciones por proceso asistencial); colegios profesionales y registros públicos aplican sus propios plazos forales.
• Sector público — Real Decreto 4/2010 (Esquema Nacional de Interoperabilidad, ENI) más Real Decreto 3/2010 (Esquema Nacional de Seguridad, ENS): el documento electrónico del sector público debe conservarse en formato preservable, con metadatos firmados, durante el plazo que establece su política de gestión documental — habitualmente plazos indefinidos para expedientes de relevancia histórica.

La consecuencia para el desarrollador es directa: la mayoría de los documentos archivables del entorno empresarial español deben sobrevivir intactos al menos 6 años (intersección LGT-LSC), y los del sector regulado o el sector público pueden requerir 10 años o más. PDF/A es el formato natural para esta horquilla; PDF estándar pierde garantías de renderizado fiel mucho antes.

Esquema Nacional de Interoperabilidad y sector público

El Real Decreto 4/2010 establece el Esquema Nacional de Interoperabilidad (ENI) — el marco normativo que rige la interoperabilidad documental entre administraciones públicas españolas. Para el desarrollador de software de gestión documental que sirve al sector público, dos normas técnicas son load-bearing:

• Norma Técnica de Interoperabilidad de Documento Electrónico — define la estructura del documento electrónico (contenido, firma, metadatos) y especifica los formatos preservables admisibles. PDF/A figura entre los formatos preferidos para la preservación de documentos textuales y de imagen rasterizada.
• Norma Técnica de Interoperabilidad de Política de Firma Electrónica — define los perfiles de firma electrónica admisibles, incluidos PAdES-B, PAdES-T, PAdES-LT y PAdES-LTV (Long-Term Validation). Para preservación a largo plazo, PAdES-LTV es la elección operativa porque embebe la información de revocación necesaria para validar la firma años después de la expiración del certificado original.

El conjunto ENI + Política de Firma define la "preservación a largo plazo" como propiedad operativa del documento: cualquier ciudadano debe poder verificar la firma del documento incluso transcurridos los plazos de validez del certificado y de la CRL original. PDF/A-2b o PDF/A-3b combinado con PAdES-LTV cubre esa exigencia.

eIDAS, servicios cualificados de preservación y PAdES

El Reglamento (UE) 910/2014 (eIDAS) regula los servicios electrónicos de confianza en el mercado interior europeo. Para el archivado a largo plazo, eIDAS introduce dos figuras relevantes:

• Servicio cualificado de preservación de firmas electrónicas cualificadas (QPSESCQS): un prestador cualificado de servicios de confianza inscrito en la lista nacional puede prolongar la verificabilidad de una firma electrónica cualificada más allá de los plazos de validez de los certificados originales. La lista española de prestadores cualificados se publica por la Secretaría de Estado de Digitalización en https://sede.serviciosmin.gob.es/Prestadores/.
• Sellos cualificados de tiempo electrónico (QTST): un sello de tiempo emitido por un TSA (Time Stamping Authority) cualificado proporciona evidencia legal de que el contenido del documento existía en un momento determinado. Para PAdES-LTV este sello debe renovarse periódicamente (re-stamping) para mantener la cadena de confianza intacta.

En el panorama ibérico, la FNMT-RCM opera una TSA cualificada (TSA-FNMT) ampliamente utilizada. AC Camerfirma, IZENPE (en territorio foral vasco) y otros prestadores ofrecen TSAs equivalentes con presencia regional o sectorial específica.

PDF/A-3b para el patrón híbrido Facturae

PDF/A-3 (ISO 19005-3:2012) es el primer perfil PDF/A que permite incrustar archivos arbitrarios como anexos preservables. Esta capacidad lo convierte en el contenedor natural del patrón híbrido factura electrónica vigente en España: un único PDF/A-3 contiene la visualización humana de la factura (la factura ordinaria que mira el receptor) y, embebido como anexo, el XML Facturae 3.2.2 con la información estructurada conforme con la norma europea EN 16931 mediante el perfil CIUS-ES.

Para el desarrollador que trabaja bajo Crea y Crece, PDF/A-3b es la versión a generar por defecto: cumple las exigencias archivísticas de larga vida, admite el XML embebido sin escindir el documento en dos archivos, y es soportado por las plataformas de cumplimiento (EDICOM, Sovos, Seres, Voxel) y por FACe. La conformidad mínima 3b (basic) es suficiente para el caso B2B; el nivel 3a (accessible + tagged) añade requisitos de etiquetado estructural útiles cuando el destinatario debe procesar el documento con tecnologías asistivas o cuando el sector regulado exige accesibilidad WCAG.

PDF/A-2b para archivado legal y mercantil

PDF/A-2 (ISO 19005-2:2011) introduce compresión JPEG2000, transparencias y capas, y la incrustación de anexos PDF/A (limitada a otros PDF/A). Es la elección natural para el archivado mercantil y de modelos AEAT cuando no hace falta embeber XML estructurado. Documentos típicos: balance de situación firmado para depósito mercantil, escrituras notariales digitalizadas, modelo 303 firmado con PAdES, justificantes de presentación telemática archivados.

PDF/A-2b mantiene amplia compatibilidad con visores españoles (Autofirma, Adobe Acrobat Reader, FNMT-Ceres) y con los entornos de archivado de plataformas privadas. Para la mayoría de los documentos archivables del entorno B2B y B2C, PDF/A-2b es la elección sensata.

PDF/A-1b para sistemas legacy y compatibilidad amplia

PDF/A-1 (ISO 19005-1:2005) es la versión más antigua y más universalmente soportada. Algunos sistemas de archivado del sector público español (registros antiguos, archivos forales con menor actualización tecnológica) sólo aceptan PDF/A-1b. Cuando el destinatario impone PDF/A-1, la conversión IronPDF aplana transparencias, sustituye JPEG2000 por JPEG, y elimina cualquier característica posterior a PDF 1.4.

PDF/A-1b es también un buen perfil para documentación pública de carácter permanente cuya audiencia incluye visores no-Adobe (LibreOffice, navegador-nativo, lectores móviles) — el principio de prudencia técnica favorece la versión más interoperable cuando no hay requisitos que la descarten.

PDF/A-4 y la transición a PDF 2.0

PDF/A-4 (ISO 19005-4:2020) se basa en PDF 2.0. Simplifica los niveles de conformidad y soporta features modernos. Su adopción en España es todavía limitada — la mayoría de plataformas de archivado, validadores (veraPDF, Adobe Acrobat Preflight) y portales públicos (FACe, sede AEAT) están calibrados sobre PDF/A-2 y PDF/A-3. Mientras esa calibración no se actualice, PDF/A-4 no es la elección recomendable para producción.

Instalación de IronPDF

Antes de empezar, instale el paquete IronPdf desde NuGet:

Install-Package IronPdf

Install-Package IronPdf

O con la CLI de .NET:

dotnet add package IronPdf

dotnet add package IronPdf

IronPDF es compatible con .NET Framework 4.6.2+, .NET Core, .NET 5+ y .NET Standard 2.0 — encaja en cualquier stack .NET del mercado español, desde aplicaciones legacy sobre .NET Framework 4.8 sobre Windows Server hasta servicios actuales en .NET 8 LTS sobre Linux + Docker.

Renderizado HTML a PDF/A

:path=/static-assets/pdf/content-code-examples/tutorials/pdfa-archiving-csharp/pdfa-render-html-to-pdfa.cs

using IronPdf;

// Create HTML content for the document
string htmlContent = @"
E html>


le>
body { font-family: Arial, sans-serif; margin: 40px; }
h1 { color: #2c3e50; }
.section { margin: 20px 0; }
table { width: 100%; border-collapse: collapse; }
th, td { border: 1px solid #ddd; padding: 10px; text-align: left; }
th { background: #3498db; color: white; }
yle>


Quarterly Financial Report</h1>
eport Period: Q4 2025</p>
 class='section'>
<table>
    <tr><th>Metric</th><th>Value</th></tr>
    <tr><td>Total Revenue</td><td>$4.2M</td></tr>
    <tr><td>Operating Expenses</td><td>$2.1M</td></tr>
    <tr><td>Net Income</td><td>$2.1M</td></tr>
</table>
v>
his document is archived in PDF/A-3b format for long-term preservation.</p>

;

// Render HTML to PDF
var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf(htmlContent);

// Save as PDF/A-3b for archival compliance
pdf.SaveAsPdfA("quarterly-report-archived.pdf", PdfAVersions.PdfA3b);

Imports IronPdf

' Create HTML content for the document
Dim htmlContent As String = "
<!DOCTYPE html>
<html>
<head>
    <style>
        body { font-family: Arial, sans-serif; margin: 40px; }
        h1 { color: #2c3e50; }
        .section { margin: 20px 0; }
        table { width: 100%; border-collapse: collapse; }
        th, td { border: 1px solid #ddd; padding: 10px; text-align: left; }
        th { background: #3498db; color: white; }
    </style>
</head>
<body>
    <h1>Quarterly Financial Report</h1>
    <p>Report Period: Q4 2025</p>
    <div class='section'>
        <table>
            <tr><th>Metric</th><th>Value</th></tr>
            <tr><td>Total Revenue</td><td>$4.2M</td></tr>
            <tr><td>Operating Expenses</td><td>$2.1M</td></tr>
            <tr><td>Net Income</td><td>$2.1M</td></tr>
        </table>
    </div>
    <p>This document is archived in PDF/A-3b format for long-term preservation.</p>
</body>
</html>
"

' Render HTML to PDF
Dim renderer As New ChromePdfRenderer()
Using pdf = renderer.RenderHtmlAsPdf(htmlContent)
    ' Save as PDF/A-3b for archival compliance
    pdf.SaveAsPdfA("quarterly-report-archived.pdf", PdfAVersions.PdfA3b)
End Using

Conversión de PDFs existentes a PDF/A

El segundo escenario habitual no parte de HTML. En proyectos de archivado masivo es frecuente recibir PDFs ya existentes — desde escáneres, sistemas legacy, repositorios documentales, recepciones de proveedores — que es necesario convertir a PDF/A para almacenamiento conforme. IronPDF lo resuelve con el mismo método SaveAsPdfA:

:path=/static-assets/pdf/content-code-examples/tutorials/pdfa-archiving-csharp/pdfa-convert-existing-pdf.cs

using IronPdf;

// Load an existing PDF file
using var pdf = PdfDocument.FromFile("existing-document.pdf");

// Convert and save as PDF/A-3b
// IronPDF automatically embeds fonts, converts color spaces, adds XMP metadata,
// and removes non-compliant features during conversion
pdf.SaveAsPdfA("existing-document-archived.pdf", PdfAVersions.PdfA3b);

// Alternative: Use ConvertToPdfA for in-memory conversion
using var pdf2 = PdfDocument.FromFile("another-document.pdf");
using var pdfA = pdf2.ConvertToPdfA(PdfAVersions.PdfA2b);
pdfA.SaveAs("another-document-archived.pdf");

Imports IronPdf

' Load an existing PDF file
Using pdf As PdfDocument = PdfDocument.FromFile("existing-document.pdf")
    ' Convert and save as PDF/A-3b
    ' IronPDF automatically embeds fonts, converts color spaces, adds XMP metadata,
    ' and removes non-compliant features during conversion
    pdf.SaveAsPdfA("existing-document-archived.pdf", PdfAVersions.PdfA3b)
End Using

' Alternative: Use ConvertToPdfA for in-memory conversion
Using pdf2 As PdfDocument = PdfDocument.FromFile("another-document.pdf")
    Using pdfA As PdfDocument = pdf2.ConvertToPdfA(PdfAVersions.PdfA2b)
        pdfA.SaveAs("another-document-archived.pdf")
    End Using
End Using

Durante la conversión, IronPDF analiza el PDF de origen y aplica las transformaciones necesarias: embebe las fuentes referenciadas pero no incrustadas, convierte espacios de color RGB o CMYK al perfil ICC apropiado, añade los metadatos XMP requeridos, y elimina las features no conformes (cifrado, multimedia, JavaScript). Si su pipeline necesita la conversión en memoria sin guardar a disco — útil cuando todavía debe firmarse con PAdES tras la conversión —, use el método ConvertToPdfA y manipule el PdfDocument resultante antes de persistirlo.

Este patrón es ideal para proyectos de migración: traer un repositorio documental legacy a conformidad con el archivado moderno sin alterar la información visual del documento original.

Anclaje en Crea y Crece y FACe

Bajo el mandato Crea y Crece (2027 para empresas con facturación > 8 M €, 2028 para el resto), el receptor de la factura B2B está obligado a procesar el documento en formato estructurado. El patrón híbrido PDF/A-3 + Facturae embebido es la solución técnicamente más limpia porque:

1. El emisor entrega un único archivo que satisface dos audiencias: el humano (departamento de cuentas a pagar del cliente) que abre el PDF y revisa la factura visualmente, y la máquina (el ERP del receptor) que extrae el XML embebido y lo procesa sin OCR.
2. El receptor elimina la necesidad de OCR — la extracción se reduce a leer el archivo Facturae.xml embebido en el PDF/A-3, validar su firma XAdES si está presente, y parsear el XML contra el esquema Facturae 3.2.2.
3. El archivo a archivar es uno solo, no dos. Reduce el coste de almacenamiento, simplifica la indexación documental, y mantiene íntegro el vínculo entre la representación visual y la información estructurada.

Para envíos B2G a través de FACe (face.gob.es), el mismo patrón aplica: el PDF/A-3 híbrido sube a la plataforma vía interfaz web o vía la API SOAP/REST que FACe expone para integraciones automáticas con ERP.

Adjuntar el XML Facturae conforme con XAdES

IronPDF cubre el lado de generación del patrón híbrido: genera el PDF/A-3 desde HTML, embebe el archivo Facturae.xml como anexo con el nombre y MIME apropiados, y aplica los metadatos XMP que identifican el documento como contenedor Facturae:

using IronPdf;
using System;
using System.IO;

// Genera el patrón híbrido PDF/A-3 + Facturae para Crea y Crece y FACe.
// El XML Facturae debe haberse generado previamente conforme al esquema
// 3.2.2 y firmado con XAdES por el certificado cualificado del emisor.
public class GeneradorPdfaFacturaeHibrido
{
    public void GenerarFacturaHibrida(
        string rutaHtmlFactura, string rutaFacturaeXml, string rutaSalida)
    {
        // Renderiza el lado visible del documento — la factura humana.
        var renderer = new ChromePdfRenderer();
        var pdf = renderer.RenderHtmlFileAsPdf(rutaHtmlFactura);

        // Convierte a PDF/A-3b y embebe el Facturae XML como anexo.
        // El nombre convencional del anexo es Facturae.xml; algunos
        // emisores legacy usan Factura-e.xml — alinear con el receptor.
        byte[] facturaeXml = File.ReadAllBytes(rutaFacturaeXml);

        pdf = pdf.ConvertToPdfA(
            PdfAVersions.PdfA3b,
            new[]
            {
                new EmbedFileConfiguration
                {
                    FileName = "Facturae.xml",
                    FileBytes = facturaeXml,
                    Description = "Facturae 3.2.2 (CIUS-ES sobre EN 16931)",
                    Relationship = AFRelationship.Source,
                    MimeType = "application/xml"
                }
            });

        pdf.SaveAs(rutaSalida);
    }
}

using IronPdf;
using System;
using System.IO;

// Genera el patrón híbrido PDF/A-3 + Facturae para Crea y Crece y FACe.
// El XML Facturae debe haberse generado previamente conforme al esquema
// 3.2.2 y firmado con XAdES por el certificado cualificado del emisor.
public class GeneradorPdfaFacturaeHibrido
{
    public void GenerarFacturaHibrida(
        string rutaHtmlFactura, string rutaFacturaeXml, string rutaSalida)
    {
        // Renderiza el lado visible del documento — la factura humana.
        var renderer = new ChromePdfRenderer();
        var pdf = renderer.RenderHtmlFileAsPdf(rutaHtmlFactura);

        // Convierte a PDF/A-3b y embebe el Facturae XML como anexo.
        // El nombre convencional del anexo es Facturae.xml; algunos
        // emisores legacy usan Factura-e.xml — alinear con el receptor.
        byte[] facturaeXml = File.ReadAllBytes(rutaFacturaeXml);

        pdf = pdf.ConvertToPdfA(
            PdfAVersions.PdfA3b,
            new[]
            {
                new EmbedFileConfiguration
                {
                    FileName = "Facturae.xml",
                    FileBytes = facturaeXml,
                    Description = "Facturae 3.2.2 (CIUS-ES sobre EN 16931)",
                    Relationship = AFRelationship.Source,
                    MimeType = "application/xml"
                }
            });

        pdf.SaveAs(rutaSalida);
    }
}

Imports IronPdf
Imports System
Imports System.IO

' Genera el patrón híbrido PDF/A-3 + Facturae para Crea y Crece y FACe.
' El XML Facturae debe haberse generado previamente conforme al esquema
' 3.2.2 y firmado con XAdES por el certificado cualificado del emisor.
Public Class GeneradorPdfaFacturaeHibrido
    Public Sub GenerarFacturaHibrida(rutaHtmlFactura As String, rutaFacturaeXml As String, rutaSalida As String)
        ' Renderiza el lado visible del documento — la factura humana.
        Dim renderer As New ChromePdfRenderer()
        Dim pdf = renderer.RenderHtmlFileAsPdf(rutaHtmlFactura)

        ' Convierte a PDF/A-3b y embebe el Facturae XML como anexo.
        ' El nombre convencional del anexo es Facturae.xml; algunos
        ' emisores legacy usan Factura-e.xml — alinear con el receptor.
        Dim facturaeXml As Byte() = File.ReadAllBytes(rutaFacturaeXml)

        pdf = pdf.ConvertToPdfA(PdfAVersions.PdfA3b, New EmbedFileConfiguration() {
            New EmbedFileConfiguration With {
                .FileName = "Facturae.xml",
                .FileBytes = facturaeXml,
                .Description = "Facturae 3.2.2 (CIUS-ES sobre EN 16931)",
                .Relationship = AFRelationship.Source,
                .MimeType = "application/xml"
            }
        })

        pdf.SaveAs(rutaSalida)
    End Sub
End Class

La relación AFRelationship.Source indica al lector PDF/A-3 que el anexo es la fuente estructurada de la presentación visual — la convención semántica que reconoce el patrón Facturae. El campo Description aparece en algunos visores como nota descriptiva del anexo y conviene marcarlo de forma legible para el departamento de cuentas a pagar del receptor.

Para los flujos donde el XML Facturae se construye en memoria antes de embeberlo (no se persiste a disco), use EmbedFileByte directamente con el byte array generado por la librería XML del emisor (System.Xml.Linq, etc.). Esto reduce el riesgo de fuga del XML intermedio durante el proceso, relevante bajo LOPDGDD cuando el archivo contiene datos personales del receptor.

PAdES-B / PAdES-LT / PAdES-LTV: niveles de conformidad

PAdES (ETSI EN 319 142) define una jerarquía de niveles donde cada uno añade evidencias adicionales sobre el anterior:

• PAdES-B (basic): firma electrónica básica. Aporta autenticidad e integridad pero no garantiza validabilidad futura — si el certificado expira o se revoca, la firma se vuelve no verificable sin información complementaria.
• PAdES-T (timestamp): añade un sello de tiempo cualificado al momento de la firma. Demuestra cuándo se firmó pero no resuelve la validabilidad a largo plazo.
• PAdES-LT (long-term): añade información de revocación (OCSP responses, CRLs) capturada en el momento de firma, embebida en un Document Security Store (DSS). Permite validar la firma sin acceso a las fuentes originales de OCSP/CRL.
• PAdES-LTV (long-term validation): es PAdES-LT más el sello de tiempo de archivado renovable — la firma puede re-sellarse periódicamente con nuevos timestamps cualificados para extender indefinidamente la cadena de confianza, incluso después de que el algoritmo de hash de la firma original quede obsoleto.

Para archivado bajo plazos LGT/LSC (6+ años) y especialmente bajo ENI (plazos indefinidos), PAdES-LTV es la elección operativa. PAdES-B es insuficiente para garantizar verificabilidad a esos horizontes; PAdES-T y PAdES-LT son mejoras intermedias pero no resuelven la obsolescencia criptográfica del hash original.

Sello de tiempo cualificado y DSS

El sello de tiempo (TSA timestamp) en PAdES-LTV debe provenir de un TSA cualificado inscrito en la lista de prestadores cualificados de servicios de confianza. En España, los TSAs habitualmente usados son:

• TSA-FNMT (tsa.fnmt.es) — operada por la FNMT-RCM. Es la TSA más extendida en el sector público y en empresas con certificados FNMT instalados.
• AC Camerfirma — TSA disponible para clientes con certificados Camerfirma; muy usada en sectores empresariales medianos y en el ámbito notarial.
• IZENPE — TSA del País Vasco, usada en territorio foral vasco junto con TicketBAI.
• Prestadores europeos (Digicert, GlobalSign, otros) — admisibles bajo el reconocimiento mutuo eIDAS si el prestador está cualificado en algún Estado miembro.

El Document Security Store (DSS) del PDF firmado embebe los certificados de la cadena, las respuestas OCSP en el momento de firma, y las CRLs aplicables. Sin DSS, la validación posterior requiere consultas externas que pueden no estar disponibles años después; con DSS, todo lo necesario para validar la firma vive dentro del propio PDF.

IronPDF cubre la firma PAdES sobre el PDF/A; para los niveles LT y LTV con DSS poblado y re-sellado periódico, el flujo habitual es delegar en una biblioteca de firma especializada (DSS de Apache Santuario, BouncyCastle con extensiones PAdES, o un servicio externo de firma cualificada) tras la generación del PDF/A con IronPDF. La arquitectura típica es: ERP genera datos → IronPDF renderiza PDF/A-3 con Facturae embebido → componente de firma aplica PAdES-LTV con certificado FNMT-RCM y TSA cualificada → archivado en repositorio documental con política de re-sellado periódico cada 5-7 años.

Fallos comunes en contexto ibérico

Aunque IronPDF resuelve la mayoría del trabajo de conformidad, ciertas condiciones de entrada producen fallos de validación. Los más frecuentes en flujos españoles:

Fuentes no embebidas con diacríticos ibéricos. Es el fallo más común. Si el PDF de origen referencia una fuente que no se embebe, o si los glifos de los diacríticos españoles (á, é, í, ó, ú, ü, ñ, ¿, ¡) no están incluidos en el subset embebido, la validación falla. Solución: garantice que las fuentes utilizadas están instaladas en el servidor donde se ejecuta IronPDF, o use fuentes web ampliamente disponibles (Arial, Verdana, Helvetica) o fuentes Google Fonts cargadas vía <link> en el HTML.

Caracteres catalanes, gallegos o vascos. Los caracteres l·l (l geminada catalana), ç (catalán, gallego), ts y tz (vasco), y la apostrofización catalana requieren glifos específicos. Si el contenido del PDF incluye texto regional español y la fuente embebida no incluye esos glifos, la conformidad se rompe. Solución: use Noto Sans (incluye todos los glifos europeos) o IBM Plex Sans para contenido multilingüe ibérico.

Espacios de color no soportados. PDF/A exige que todos los colores estén definidos con un perfil ICC embebido (habitualmente sRGB para documentos de pantalla, un perfil CMYK para documentos impresos). PDFs con espacios de color dependientes del dispositivo sin perfil embebido fallan. Solución: IronPDF maneja la conversión automáticamente; en casos límite, asegúrese de que el HTML origen especifica colores en sRGB.

Cifrado o protección con contraseña. PDF/A prohíbe estrictamente el cifrado. Si convierte un PDF protegido con contraseña, debe descifrarlo primero. Solución: use PdfDocument.FromFile("protegido.pdf", "contraseña") para abrir el archivo protegido antes de la conversión.

JavaScript o contenido multimedia. PDF/A prohíbe JavaScript, audio, vídeo y elementos interactivos. Si el HTML origen incluye etiquetas <script>, vídeo embebido o formularios interactivos, deberá eliminarlos antes del renderizado. Solución: garantice que el HTML está limpio de contenido activo.

Transparencias en PDF/A-1. PDF/A-1 no admite transparencia. Si el documento contiene elementos transparentes (habitual en diseños CSS modernos), la conversión a PDF/A-1 requiere aplanado. Solución: apunte a PDF/A-2 o PDF/A-3 si su diseño usa transparencia, o garantice que el CSS no usa opacity, rgba o PNGs transparentes cuando apunte a PDF/A-1.

Fuentes, perfiles de color y metadatos XMP

Los tres pilares de la conformidad PDF/A — fuentes, espacios de color, metadatos — merecen un repaso final.

Fuentes: cada fuente usada debe estar totalmente embebida (no en subset incompleto). Para los niveles a de conformidad (PDF/A-1a, PDF/A-2a, PDF/A-3a), cada carácter debe además tener mapeo Unicode, garantizando que el texto sea extraíble y buscable. Para contenido ibérico, recomendable: Noto Sans, IBM Plex Sans, Source Sans Pro — todas con cobertura completa de los diacríticos español-catalán-vasco-gallego y mapeo Unicode íntegro.

Espacios de color: PDF/A exige espacios de color independientes del dispositivo respaldados por perfil ICC. En la práctica, sRGB para la mayoría de documentos. IronPDF embebe el perfil ICC apropiado y convierte colores automáticamente durante SaveAsPdfA; opcionalmente puede pasar una ruta a un perfil ICC personalizado si el flujo lo requiere. Para documentos orientados a impresión con precisión CMYK, garantice que el contenido origen use perfiles CMYK adecuados y que se conserven durante la conversión.

Metadatos XMP: PDF/A requiere metadatos XMP (Extensible Metadata Platform) embebidos. Incluye título del documento, autor, fecha de creación, fecha de modificación, y el identificador del nivel de conformidad PDF/A. IronPDF puebla estos campos automáticamente, y permite establecerlos explícitamente vía la propiedad MetaData cuando hace falta control fino:

:path=/static-assets/pdf/content-code-examples/tutorials/pdfa-archiving-csharp/pdfa-metadata-settings.cs

using IronPdf;
using System;

// Create a PDF document
var renderer = new ChromePdfRenderer();
using var pdf = renderer.RenderHtmlAsPdf("<h1>Annual Report 2025</h1><p>Corporate performance summary.</p>");

// Set standard metadata properties
pdf.MetaData.Title = "Annual Report 2025 - IronSoftware Inc.";
pdf.MetaData.Author = "Finance Department";
pdf.MetaData.Subject = "Corporate annual financial and operational report";
pdf.MetaData.Keywords = "annual report, financial, 2025, corporate, IronSoftware";
pdf.MetaData.Creator = "IronPDF Document Generator";
pdf.MetaData.CreationDate = DateTime.Now;
pdf.MetaData.ModifiedDate = DateTime.Now;

// For custom or batch metadata, use SetMetaDataDictionary
var metadataDict = new System.Collections.Generic.Dictionary<string, string>
{
    { "Title", "Quarterly Report Q4 2025" },
    { "Author", "Finance Team" },
    { "Subject", "Q4 Financial Results" },
    { "Keywords", "quarterly, Q4, 2025, finance" },
    { "Department", "Finance" },
    { "Classification", "Internal" },
    { "RetentionPeriod", "7 years" }
};

using var pdf2 = renderer.RenderHtmlAsPdf("<h1>Q4 Report</h1>");
pdf2.MetaData.SetMetaDataDictionary(metadataDict);

// Convert to PDF/A with metadata preserved
pdf.SaveAsPdfA("annual-report-2025.pdf", PdfAVersions.PdfA3b);
pdf2.SaveAsPdfA("q4-report-2025.pdf", PdfAVersions.PdfA3b);

Imports IronPdf
Imports System
Imports System.Collections.Generic

' Create a PDF document
Dim renderer As New ChromePdfRenderer()
Using pdf = renderer.RenderHtmlAsPdf("<h1>Annual Report 2025</h1><p>Corporate performance summary.</p>")

    ' Set standard metadata properties
    pdf.MetaData.Title = "Annual Report 2025 - IronSoftware Inc."
    pdf.MetaData.Author = "Finance Department"
    pdf.MetaData.Subject = "Corporate annual financial and operational report"
    pdf.MetaData.Keywords = "annual report, financial, 2025, corporate, IronSoftware"
    pdf.MetaData.Creator = "IronPDF Document Generator"
    pdf.MetaData.CreationDate = DateTime.Now
    pdf.MetaData.ModifiedDate = DateTime.Now

    ' For custom or batch metadata, use SetMetaDataDictionary
    Dim metadataDict As New Dictionary(Of String, String) From {
        {"Title", "Quarterly Report Q4 2025"},
        {"Author", "Finance Team"},
        {"Subject", "Q4 Financial Results"},
        {"Keywords", "quarterly, Q4, 2025, finance"},
        {"Department", "Finance"},
        {"Classification", "Internal"},
        {"RetentionPeriod", "7 years"}
    }

    Using pdf2 = renderer.RenderHtmlAsPdf("<h1>Q4 Report</h1>")
        pdf2.MetaData.SetMetaDataDictionary(metadataDict)

        ' Convert to PDF/A with metadata preserved
        pdf.SaveAsPdfA("annual-report-2025.pdf", PdfAVersions.PdfA3b)
        pdf2.SaveAsPdfA("q4-report-2025.pdf", PdfAVersions.PdfA3b)
    End Using
End Using

Establecer metadatos explícitamente es especialmente importante para documentos que serán indexados por sistemas de gestión documental del sector público español bajo ENI — los campos title, author y subject se usan habitualmente como índice de catalogación y búsqueda en los repositorios SEDIA y Archive.

Archivado AEAT y libros registro SII

Las empresas obligadas al Suministro Inmediato de Información (SII) — grandes empresas con facturación superior a 6,01 M €, grupos de IVA, contribuyentes inscritos en REDEME — están obligadas a llevar los libros registro de IVA electrónicamente y a remitir la información casi en tiempo real (4 días naturales) a la sede electrónica de la AEAT. La información se intercambia en formato XML estructurado, pero los justificantes de presentación, las copias de las facturas emitidas y recibidas, los modelos de declaración (303, 390, 347, 720, etc.) deben conservarse en formato preservable durante los plazos LGT.

El patrón típico es:

1. El ERP genera la factura — IronPDF la renderiza como PDF/A-3 con Facturae embebido.
2. El sistema firma la factura con PAdES-LTV (certificado FNMT-RCM del emisor + TSA-FNMT).
3. El archivo firmado se conserva en el repositorio documental durante el plazo LGT (4-6 años mínimo, ampliable).
4. Para modelos AEAT (Modelo 303 mensual/trimestral, Modelo 390 anual), el justificante de presentación telemática se descarga desde la sede AEAT en PDF; IronPDF lo convierte a PDF/A-2b y aplica PAdES-LTV antes de archivar.
5. Los libros registro de IVA bajo SII se persisten en su forma estructurada XML, pero los volcados periódicos (mensual, trimestral) se archivan también como PDF/A-2b para facilitar la consulta humana en auditorías.

Sector público bajo ENI

El sector público español está obligado por el Real Decreto 4/2010 y por la Ley 39/2015 LPAC a la gestión documental electrónica con preservación a largo plazo. El patrón típico para un ayuntamiento, una consejería autonómica o un ministerio:

1. El expediente administrativo genera documentos (resoluciones, notificaciones, justificantes) en formato editable (Word, ODT).
2. Cuando el documento debe firmarse y archivarse, se renderiza a PDF, IronPDF lo convierte a PDF/A-2b o PDF/A-3a (para accesibilidad WCAG/Real Decreto 1112/2018), y se firma con PAdES-LTV con el certificado de empleado público correspondiente.
3. El documento firmado se persiste en el archivo electrónico junto con sus metadatos ENI (clasificación documental, tabla de retención, política de firma aplicada).
4. Para expedientes archivables de relevancia histórica, la política de gestión documental define el plazo de transferencia al archivo histórico (provincial, regional, nacional) y la conservación es indefinida con re-sellado periódico de la firma PAdES-LTV.

Plataformas habituales en este flujo: Inside, ARTAS, GEISER, DocuWare España, ConsumeQR, Plataforma de Intermediación de Datos (PID) del Ministerio. IronPDF se integra dentro del producto del integrador que ofrece la solución de gestión documental al organismo, no como sistema completo.

Banca, seguros y sanidad

Tres sectores regulados con plazos de conservación extendidos:

• Banca (Banco de España + Real Decreto 84/2015): contratos bancarios, expediente del cliente bajo conocimiento del cliente (KYC), justificantes de operaciones — plazos típicos de 10 años desde el cese de la relación comercial. PDF/A-2b con PAdES-LTV es el estándar operativo.
• Seguros (DGSFP + Real Decreto-Ley 3/2020): pólizas, expedientes de siniestro, comunicaciones contractuales — plazos típicos de 6 a 10 años según la naturaleza del producto. PDF/A-3b si la póliza incluye XML estructurado (Sinco / Norma Técnica del CCS para automoción); PDF/A-2b para el resto.
• Sanidad (Ley 41/2002): historia clínica del paciente — 5 años desde la última asistencia como plazo legal mínimo, con excepciones por proceso asistencial activo o por exigencias administrativas o judiciales. Para historia clínica de larga vida (pediatría → adulto, enfermedades crónicas), el plazo efectivo se extiende décadas. PDF/A-3a (con tagging accesible) es la elección recomendable, alineada con las exigencias LOPDGDD/AEPD sobre datos especialmente protegidos del sector sanitario.

En los tres sectores, la arquitectura habitual es: aplicación de negocio del sector → renderizado PDF con IronPDF → conversión a PDF/A apropiado → firma PAdES-LTV con certificado corporativo o con representación de la entidad (cualificado eIDAS si lo requiere la normativa sectorial) → archivado en el repositorio documental sectorial con políticas de retención específicas → re-sellado periódico de la firma para mantener verificabilidad a lo largo del plazo.