Formularios PDF AcroForm en C# para Modelos AEAT, FACe y sector público español

Modelos AEAT como AcroForm: el formato dominante

Los Modelos AEAT son los formularios oficiales que la Agencia Estatal de Administración Tributaria publica para las distintas obligaciones tributarias. La sede electrónica (sede.agenciatributaria.gob.es) los publica en formato PDF AcroForm — los descarga el contribuyente, los cumplimenta (manualmente, mediante AutoFirma con clave PIN, o programáticamente desde su software de gestión), los firma con certificado FNMT-RCM o equivalente, y los presenta telemáticamente vía sede electrónica. Los Modelos más frecuentes en flujo automatizado:

• Modelo 303 — IVA trimestral. El más voluminoso por frecuencia (cuatro veces al año) y por número de contribuyentes obligados. Una gestoría mediana presenta cientos al trimestre.
• Modelo 390 — IVA anual. Resumen del ejercicio fiscal completo. Presentación obligatoria para sujetos pasivos del IVA en régimen general.
• Modelo 347 — Declaración informativa de operaciones con terceros. Anual; incluye relación detallada de clientes y proveedores con los que se han realizado operaciones superiores a 3.005,06 € en el ejercicio.
• Modelo 720 — Declaración informativa de bienes y derechos situados en el extranjero. Obligatoria para residentes fiscales españoles con bienes superiores a 50.000 € en el exterior.
• Modelos 130 y 131 — IRPF autónomos trimestral (130 estimación directa, 131 estimación objetiva).
• Modelos 200 y 202 — Impuesto sobre Sociedades anual y pagos fraccionados.
• Modelo 100 — IRPF declaración anual del ciudadano.

Cada modelo tiene su versión vigente del PDF AcroForm con sus identificadores de campo específicos. La AEAT publica cada año la versión actualizada (frecuentemente con ajustes técnicos: nuevas casillas para tratamiento de novedades fiscales, ajustes de tipos de IVA, modificaciones en el régimen de IRPF). El desarrollador que automatiza la presentación de Modelos AEAT debe contemplar la evolución anual del formulario — los nombres de campo internos cambian entre versiones.

FACe y los formularios B2G del sector público

FACe (face.gob.es) — el Punto General de Entrada de Facturas Electrónicas de la Administración General del Estado — es el portal donde los proveedores del sector público envían sus facturas electrónicas en formato Facturae XML. Adicionalmente, FACe expone formularios PDF AcroForm para casos donde el envío automatizado no es viable (proveedores ocasionales, pruebas, recuperación de datos para incidencias). Estos formularios incluyen campos identificativos del emisor (NIF/CIF, razón social, dirección fiscal), del receptor (NIF del organismo público destinatario, código DIR3 de la unidad), y de la factura (número, fecha, importe, partidas).

Para Comunidades Autónomas que operan su propio Punto General de Entrada (algunas grandes — Cataluña con e.FACT, País Vasco con eFactura, Madrid con FACeB2B), los formularios pueden diferir ligeramente, pero la estructura técnica AcroForm es la misma.

Justificantes VeriFactu y archivado de presentaciones

Bajo el régimen VeriFactu (RDL 15/2025, vigente desde 1 ene 2027 para Impuesto de Sociedades / 1 jul 2027 para resto), cada factura emitida genera un registro de facturación con su huella encadenada. El justificante de la operación incluye un PDF que en algunos sistemas se distribuye como AcroForm rellenable (especialmente en flujos donde un humano interactúa antes de la presentación definitiva).

Los justificantes de presentación de Modelos AEAT también son AcroForm en muchos casos — la sede AEAT confirma la presentación entregando un PDF firmado con código CSV de verificación, que constituye prueba legal de la presentación. Este PDF debe archivarse bajo plazo LGT (4 años mínimo, ampliables a 10 con interrupción de prescripción).

Abrir y listar campos de un Modelo AEAT

El primer paso de cualquier flujo de automatización es identificar los nombres internos de los campos del formulario. IronPDF expone pdf.Form.Fields con todos los campos del AcroForm cargado:

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-forms-csharp-article/list-form-fields.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Los nombres de campo en los Modelos AEAT no son legibles — son códigos internos como m303_iva_general_base, m303_iva_general_cuota, m303_nif_declarante. Conviene mantener un mapa entre nombres internos del campo y campos lógicos del dominio del sistema. Estos mapas deben actualizarse anualmente cuando la AEAT publica la versión del Modelo del nuevo ejercicio fiscal.

Tipos de campo en formularios ibéricos

Los Modelos AEAT y formularios FACe usan los cinco tipos estándar de AcroForm:

• Texto — NIF, razón social, dirección, casillas numéricas (importes, contadores).
• Checkbox — opciones binarias (acogimiento a régimen especial, declaración complementaria, etc.).
• Radio button — opciones excluyentes (estimación directa vs objetiva en IRPF, régimen general vs simplificado).
• Dropdown — listas cerradas (provincia, tipo de operación).
• Firma — campo de firma electrónica con certificado FNMT-RCM.

La AEAT habitualmente protege los campos calculados (total a ingresar = base × tipo IVA − retenciones) — son de sólo lectura desde la perspectiva del software cliente. El cálculo lo hace el formulario internamente mediante JavaScript del AcroForm. Esta dependencia interna del formulario es un detalle a respetar: IronPDF puede rellenar los campos de entrada pero los campos calculados se actualizan al abrir el formulario en un visor compatible con AcroForm JavaScript (Adobe Acrobat, FNMT-Ceres).

Validación del NIF con dígito de control

El NIF español tiene tres variantes formales y un dígito de control calculable. Antes de rellenar el campo NIF del Modelo AEAT, valídelo en cliente para evitar rechazos posteriores en la presentación:

using System.Text.RegularExpressions;

// Validador de NIF español. Cubre las tres variantes: NIF de persona física
// (8 dígitos + letra control), CIF histórico de entidades (letra + 7 dígitos
// + control), y NIE de residentes extranjeros (X/Y/Z + 7 dígitos + letra).
public static class ValidadorNif
{
    private const string LETRAS_CONTROL = "TRWAGMYFPDXBNJZSQVHLCKE";

    public static bool EsValido(string nif)
    {
        if (string.IsNullOrEmpty(nif)) return false;
        nif = nif.ToUpperInvariant().Replace(" ", "").Replace("-", "");

        // NIF persona física: 8 dígitos + letra control
        var matchPersona = Regex.Match(nif, @"^(\d{8})([A-Z])$");
        if (matchPersona.Success)
        {
            int numero = int.Parse(matchPersona.Groups[1].Value);
            char letraEsperada = LETRAS_CONTROL[numero % 23];
            return matchPersona.Groups[2].Value[0] == letraEsperada;
        }

        // CIF entidad: letra + 7 dígitos + dígito de control
        var matchCif = Regex.Match(nif, @"^([A-HJ-NP-SUVW])(\d{7})(\d|[A-J])$");
        if (matchCif.Success)
        {
            // El cálculo del control CIF es más complejo (par/impar, módulo 10).
            // En implementación de producción usar librería específica.
            return true;
        }

        // NIE: X/Y/Z + 7 dígitos + letra control
        var matchNie = Regex.Match(nif, @"^([XYZ])(\d{7})([A-Z])$");
        if (matchNie.Success)
        {
            int prefijo = "XYZ".IndexOf(matchNie.Groups[1].Value[0]);
            int numero = int.Parse(prefijo.ToString() + matchNie.Groups[2].Value);
            char letraEsperada = LETRAS_CONTROL[numero % 23];
            return matchNie.Groups[3].Value[0] == letraEsperada;
        }

        return false;
    }
}

using System.Text.RegularExpressions;

// Validador de NIF español. Cubre las tres variantes: NIF de persona física
// (8 dígitos + letra control), CIF histórico de entidades (letra + 7 dígitos
// + control), y NIE de residentes extranjeros (X/Y/Z + 7 dígitos + letra).
public static class ValidadorNif
{
    private const string LETRAS_CONTROL = "TRWAGMYFPDXBNJZSQVHLCKE";

    public static bool EsValido(string nif)
    {
        if (string.IsNullOrEmpty(nif)) return false;
        nif = nif.ToUpperInvariant().Replace(" ", "").Replace("-", "");

        // NIF persona física: 8 dígitos + letra control
        var matchPersona = Regex.Match(nif, @"^(\d{8})([A-Z])$");
        if (matchPersona.Success)
        {
            int numero = int.Parse(matchPersona.Groups[1].Value);
            char letraEsperada = LETRAS_CONTROL[numero % 23];
            return matchPersona.Groups[2].Value[0] == letraEsperada;
        }

        // CIF entidad: letra + 7 dígitos + dígito de control
        var matchCif = Regex.Match(nif, @"^([A-HJ-NP-SUVW])(\d{7})(\d|[A-J])$");
        if (matchCif.Success)
        {
            // El cálculo del control CIF es más complejo (par/impar, módulo 10).
            // En implementación de producción usar librería específica.
            return true;
        }

        // NIE: X/Y/Z + 7 dígitos + letra control
        var matchNie = Regex.Match(nif, @"^([XYZ])(\d{7})([A-Z])$");
        if (matchNie.Success)
        {
            int prefijo = "XYZ".IndexOf(matchNie.Groups[1].Value[0]);
            int numero = int.Parse(prefijo.ToString() + matchNie.Groups[2].Value);
            char letraEsperada = LETRAS_CONTROL[numero % 23];
            return matchNie.Groups[3].Value[0] == letraEsperada;
        }

        return false;
    }
}

Imports System.Text.RegularExpressions

' Validador de NIF español. Cubre las tres variantes: NIF de persona física
' (8 dígitos + letra control), CIF histórico de entidades (letra + 7 dígitos
' + control), y NIE de residentes extranjeros (X/Y/Z + 7 dígitos + letra).
Public Module ValidadorNif
    Private Const LETRAS_CONTROL As String = "TRWAGMYFPDXBNJZSQVHLCKE"

    Public Function EsValido(nif As String) As Boolean
        If String.IsNullOrEmpty(nif) Then Return False
        nif = nif.ToUpperInvariant().Replace(" ", "").Replace("-", "")

        ' NIF persona física: 8 dígitos + letra control
        Dim matchPersona = Regex.Match(nif, "^(\d{8})([A-Z])$")
        If matchPersona.Success Then
            Dim numero As Integer = Integer.Parse(matchPersona.Groups(1).Value)
            Dim letraEsperada As Char = LETRAS_CONTROL(numero Mod 23)
            Return matchPersona.Groups(2).Value(0) = letraEsperada
        End If

        ' CIF entidad: letra + 7 dígitos + dígito de control
        Dim matchCif = Regex.Match(nif, "^([A-HJ-NP-SUVW])(\d{7})(\d|[A-J])$")
        If matchCif.Success Then
            ' El cálculo del control CIF es más complejo (par/impar, módulo 10).
            ' En implementación de producción usar librería específica.
            Return True
        End If

        ' NIE: X/Y/Z + 7 dígitos + letra control
        Dim matchNie = Regex.Match(nif, "^([XYZ])(\d{7})([A-Z])$")
        If matchNie.Success Then
            Dim prefijo As Integer = "XYZ".IndexOf(matchNie.Groups(1).Value(0))
            Dim numero As Integer = Integer.Parse(prefijo.ToString() & matchNie.Groups(2).Value)
            Dim letraEsperada As Char = LETRAS_CONTROL(numero Mod 23)
            Return matchNie.Groups(3).Value(0) = letraEsperada
        End If

        Return False
    End Function
End Module

Bajo LOPDGDD, un Modelo AEAT presentado con NIF inválido entra inmediatamente en el flujo de cola de revisión manual de la AEAT — el contribuyente es notificado de la incidencia y la presentación queda en suspenso hasta su corrección. Validar en cliente evita estas notificaciones y mantiene la trazabilidad del proceso.

IVA al 21/10/4 %, retenciones IRPF y bases imponibles

Los Modelos AEAT distinguen las bases imponibles por tipo de IVA: general (21 %), reducido (10 %), superreducido (4 %), exento, no sujeto. La cuota se calcula multiplicando base × tipo. En el Modelo 303 trimestral las casillas habituales son:

• Casilla 01 — base imponible operaciones interiores tipo general (21 %)
• Casilla 03 — base imponible operaciones interiores tipo reducido (10 %)
• Casilla 05 — base imponible operaciones interiores tipo superreducido (4 %)
• Casilla 02, 04, 06 — cuotas IVA correspondientes a las casillas 01, 03, 05
• Casillas 07-08 — recargo de equivalencia (minoristas en régimen especial)
• Casilla 28 — base imponible operaciones intracomunitarias
• Casilla 41 — retenciones IRPF practicadas en el período

Para servicios profesionales, la retención IRPF es típicamente 15 % (régimen general) o 7 % (alta inicial autónomos durante los tres primeros años). Para arrendamientos urbanos la retención es 19 %. Estos tipos cambian periódicamente — consulte la normativa vigente al inicio del ejercicio fiscal.

Prefill de Modelo 303 desde libro registro SII

Las empresas obligadas al Suministro Inmediato de Información (SII) — facturación superior a 6,01 M €, grupos de IVA, inscritos en REDEME — llevan sus libros registro de IVA electrónicamente y los remiten en tiempo casi real a la AEAT. El Modelo 303 trimestral se puede prefill desde estos libros:

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-forms-csharp-article/prefill-modelo-303-sii.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

El patrón es: el ERP agrega las facturas emitidas y recibidas del trimestre desde el libro SII, calcula las bases imponibles por tipo de IVA, descarga el Modelo 303 vigente desde la sede AEAT, IronPDF rellena los campos numéricos correspondientes, el contribuyente revisa y firma con su certificado FNMT-RCM, y el sistema presenta el Modelo telemáticamente vía la pasarela de la AEAT.

Prefill de Modelo 347 desde extracción de facturas anuales

El Modelo 347 — Declaración informativa de operaciones con terceros — agrega las operaciones con cada cliente y proveedor cuyo total anual supera 3.005,06 €. El prefill desde el ERP requiere:

1. Extracción de operaciones anuales agrupadas por NIF de contraparte
2. Filtrado de las contrapartes cuyo total anual supera el umbral
3. Distinción de operaciones por trimestre (el Modelo 347 desglosa por trimestre)
4. Rellenado de la tabla de detalle del Modelo con NIF, razón social, importe trimestral, importe anual

El Modelo 347 puede llegar a tener cientos de líneas de detalle para empresas medianas — la automatización es prácticamente obligatoria. Sin ella, la cumplimentación manual es propensa a errores que la AEAT detecta mediante el cruce automático con los Modelos 347 que presentan los proveedores y clientes (mismatch detection).

Datos cumplimentados por el ciudadano

Cuando el flujo invierte el sentido — un Modelo AEAT cumplimentado por un cliente externo que la gestoría recibe para procesar — la extracción usa el mismo pdf.Form.Fields para leer cada campo:

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-forms-csharp-article/extract-form-data.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Reconciliación con sistemas internos del despacho

Para gestorías que reciben cientos de Modelos por temporada, la extracción se conecta con el sistema interno de gestión del despacho: cada Modelo extraído se carga en la ficha del cliente correspondiente, los importes se contrastan contra la contabilidad ya cargada en el sistema, y las discrepancias se elevan al gestor para resolución manual. Bajo LOPDGDD, los datos del ciudadano (NIF, importes, datos identificativos) están sujetos a las medidas técnicas y organizativas que el RGPD impone — almacenamiento cifrado, acceso restringido al personal con necesidad operativa, registro de accesos para auditoría.

Aplanado del formulario tras la firma

Una vez cumplimentado y firmado el Modelo AEAT, conviene aplanar el AcroForm para fijar los valores y prevenir modificación posterior. El aplanado convierte los campos interactivos en contenido estático:

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-forms-csharp-article/flatten-form.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

El aplanado debe hacerse antes o después de la firma según el flujo:

• Antes de la firma: si la firma debe cubrir el contenido literal del documento. El aplanado se hace, el documento aplanado se firma, el resultado es inalterable.
• Después de la firma: si la firma sólo debe cubrir el AcroForm original (sin aplanar). En este caso el aplanado se hace sobre un duplicado, separando la versión firmada (no aplanada, conservada para verificación criptográfica) del documento aplanado para distribución legible.

Archivado bajo plazos LGT con PAdES-LTV

Los Modelos AEAT presentados deben conservarse bajo los plazos de la Ley General Tributaria (4 años de prescripción general, ampliables a 10 años para inversiones plurianuales o por interrupciones de la prescripción). El justificante de presentación firmado por la AEAT (con código CSV) debe archivarse junto con el Modelo presentado, en formato preservable PDF/A-2b o PDF/A-3b, con firma PAdES-LTV que mantenga la verificabilidad a lo largo del plazo.

El flujo completo de archivado se cubre en detalle en el tutorial Archivado electrónico de facturas y documentos en C# con PDF/A para España. Para el flujo de Modelos AEAT específicamente: PDF AcroForm aplanado → conversión a PDF/A-2b → firma PAdES-LTV con certificado FNMT-RCM del responsable de la presentación → almacenamiento en repositorio documental con política de retención LGT.

Batch de Modelos 303 al cierre trimestral

Una gestoría que presenta Modelos 303 de cientos de clientes al final de cada trimestre necesita procesar la cola en paralelo controlado. El patrón:

:path=/static-assets/pdf/content-code-examples/tutorials/pdf-forms-csharp-article/batch-modelo-303.cs

// ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

' ¡ESTE FRAGMENTO DE CÓDIGO NO ESTÁ DISPONIBLE!

Configurar SemaphoreSlim con concurrencia 3-5 evita saturar la pasarela telemática de la AEAT (que tiene umbrales de carga por NIF presentador), y respeta el plazo SII de cuatro días naturales sin acumular operaciones pendientes más allá del periodo permitido.

Generación masiva FACe para sector público

Para proveedores con alto volumen de facturación al sector público (suministradores energéticos, telecomunicaciones, mantenimiento), la generación masiva FACe del cierre mensual sigue el mismo patrón. La diferencia es que cada factura genera no sólo el AcroForm FACe sino también el Facturae XML estructurado, el patrón híbrido PDF/A-3 con Facturae embebido, y la firma PAdES sobre el PDF visualizable. IronPDF puede aplicar todas estas operaciones en un único pipeline.