Verifactu
WorkToCloud
Facturación electrónica AEAT
Para clientes registrados en WorkToCloud. Vincula tu cuenta Manager, sube tu certificado y completa el modo demo antes de producción.
Manual: crear y exportar el certificado electrónico (sin login)
Clientes registrados en WorkToCloud. Introduce las credenciales de tu cuenta Manager.
Tu cuenta WorkToCloud aún no está registrada aquí. Completa los datos y sube el certificado .p12. La cuenta se creará siempre en modo demo.
Registro de la primera aceptación de los documentos del servicio Verifactu.
Elige el diseño de las facturas nuevas. Las ya emitidas conservan el diseño con el que se crearon. Verifct Basic incluye 2 plantillas; el resto forma parte de Verifct Pro.
Cada app es una línea de facturación (SIF) con su propio AppId, AppSecret y nº de instalación AEAT. El secret solo se muestra al crearla.
Con Verifct Basic solo puedes tener 1 aplicación. Más apps y mayor capacidad llegarán con Verifct Pro.
Guarda el AppSecret ahora (no se volverá a mostrar):
| Nombre | AppId | Estado | Modo | Último uso |
|---|
Nº instalación AEAT: —
Cada app tiene su propia serie. %n y solo con %Y. Se guarda al salir del campo.
Demo = preproducción Hacienda (cualquier origen). Real requiere pruebas demo de esta app y restringe orígenes.
En modo real la API solo acepta estos orígenes. En demo no se aplica la restricción.
Límites de plataforma (hora y día). Si requiere aumentar los límites, al acercarse al 80 % del consumo podrá solicitar el aumento.
Apps en modo demo. Por defecto aparecen compactadas: pulsa el nombre para ver las pruebas. Las completadas se marcan con fecha; el icono ! solo aparece si hay errores.
Pasa el ratón por Origen o AEAT para ver canal (API / Manual / Prueba demo) o huella.
| Fecha | Número | Tipo | Cliente | Total | Origen | App | AEAT |
|---|
Rechazos AEAT de facturas (p. ej. código 1239) y fallos del panel/API. No confundir con «Peticiones API».
Registro de respuestas con error, orígenes no permitidos, rate limit y bloqueos. Las peticiones correctas no saturan este listado.
IPs bloqueadas para tu empresa. También se añaden automáticamente ante abuso: origen denegado (≥12/10 min), rate limit (≥25/10 min), auth fallida (≥20/10 min) o muchos errores (≥40/5 min). Las globales de plataforma las gestiona WorkToCloud.
En Verifactu cada documento lleva un código corto (F1, F2…). Indican qué tipo de factura estás emitiendo ante Hacienda.
Es la factura “de toda la vida” a un cliente identificado: nombre, NIF/CIF y, normalmente, dirección. Sirve cuando el receptor necesita la factura para su contabilidad o para deducir el IVA.
Ejemplo: una agencia de marketing factura 2.000 € + IVA a Panadería López S.L. (CIF B12345678) por una campaña. Esa factura es F1.
Es el ticket corto: no hace falta identificar al comprador con NIF. Se usa en ventas rápidas al público, con límites legales de importe (como en un TPV o un ticket de bar).
Ejemplo: una cafetería cobra 4,50 € por un café y un croissant. El ticket no lleva el NIF del cliente. Eso es F2.
Corrige una factura anterior que ya se emitió (importe, concepto, IVA…). La original no desaparece: queda en el historial y la rectificativa dice “esto cambia aquello”. Es lo habitual cuando te has equivocado o hay un abono parcial.
Ejemplo: emitiste una F1 de 121 € (100 + IVA) por un servicio, pero el cliente solo usó la mitad. Emites una R1 de −60,50 € que referencia la factura original. No hace falta “borrar” la primera.
Cuando alguien pide la factura “completa” a partir de un ticket F2 (por ejemplo, para presentar gastos en su empresa), emites una F3 que sustituye esa simplificada: ahora sí identifica al cliente.
Ejemplo: un cliente pide factura con NIF del ticket de 45 € del hotel. Generas una F3 que sustituye al F2 y ya aparece su CIF.
Cancela un registro concreto ante Hacienda (como si esa factura no debiera haberse enviado). No es el camino habitual para corregir un importe: para eso está la rectificativa. La anulación encaja en casos muy concretos (por ejemplo, un ticket F2 duplicado o emitido por error el mismo día en un TPV). La normativa no limita la anulación al trimestre fiscal en curso; sí conviene hacerlo cuanto antes por la liquidación de IVA.
Ejemplo: el TPV imprimió dos veces el mismo ticket de 12 € por un fallo de red. Anulas el duplicado. Si en cambio cobraste de más y quieres devolver dinero, lo normal es una R1, no anular.
Resumen rápido
Dudas técnicas, contables y de uso del panel o la API. Pulsa cada pregunta para ver la respuesta.
Ninguna FAQ coincide con ese texto.
La Agencia Tributaria ha rechazado el bloque Destinatario (cliente): el NIF/CIF y/o la razón social no cuadran con el censo (NIF inválido, no censado, o nombre que no corresponde a ese NIF).
No. Un rechazo no es un alta aceptada. No hay obligación de emitir un registro de anulación “porque no se tramitó”. Lo correcto es corregir los datos y reenviar el mismo registro como subsanación.
La anulación sirve cuando el alta sí fue aceptada y quieres dejar sin efecto esa operación (p. ej. ticket duplicado).
Los rechazos AEAT (códigos 1239, 2001…) viven en Errores → Errores y en el estado AEAT de cada factura. La subpestaña Peticiones API solo lista fallos HTTP de la API (IP no autorizada, rate limit, credenciales, blacklist…), no el detalle fiscal de la AEAT.
Sí para facturas futuras: la AEAT fija el registro, la huella, el QR y las menciones legales, no el diseño visual del PDF. Las facturas ya emitidas conservan la plantilla con la que se crearon; no se reescriben los PDF antiguos al cambiar de plantilla.
Por línea puedes elegir IVA (Península y Baleares), IGIC (Canarias) o IPSI (Ceuta y Melilla), con sus tipos habituales. También exenta (motivos E1–E6) o no sujeta.
Elige el tipo según cómo factures en la realidad; Hacienda valida la coherencia del bloque Destinatario.
Verifct Basic incluye 2 plantillas. El resto (más diseños, editor, límites ampliados, más de una app…) forma parte de Verifct Pro. Las facturas ya emitidas no cambian de plantilla al elegir otra.
En el registro / vinculación de la cuenta debes abrirlas y aceptarlas. En Mi Cuenta → Documentación queda el registro de esa primera aceptación (con enlace Ver). No se vuelven a pedir como botones «Abrir» en esa pantalla.
La IP está en la blacklist (manual o automática por abuso: muchos orígenes denegados, rate limit, auth fallida…). Las llamadas desde el propio panel (alta manual / demo) no deben bloquearse por IP: usan un token interno. Las llamadas externas con AppId/AppSecret sí respetan la blacklist y los orígenes autorizados en producción.
VF_IP_UNAUTHORIZED (401).No es recomendable. El AppSecret quedaría expuesto. Llama siempre desde tu backend (PHP, Node, Java…).
En cada petición: X-App-Id y X-App-Secret (o los mismos como query). La ruta debe incluir la versión, p. ej. /api/v1/invoices.
El alta queda en cola del SIF. Debes invocar el flujo de process (o el que use tu integración) para remitírsela a la AEAT. En el panel, al emitir una factura manual, el process se dispara automáticamente.
A efectos Verifactu ante Hacienda, el registro no está aceptado. A efectos comerciales, si ya entregaste un PDF al cliente con datos erróneos, conviene corregir la documentación que le diste y, si la operación económica sigue viva, emitir la factura correcta (tras subsanar el registro o según tu procedimiento interno).
No. Los registros son inmutables. Se corrigen con subsanación, rectificativa o anulación, según el caso; el historial permanece auditable.
No. La anulación no libera el número: ese documento ya quedó registrado ante Hacienda (serie, número, fecha y huella). Debes continuar con el siguiente correlativo de la serie.
Si necesitas corregir importes o sustituir la operación, emite una factura rectificativa con otro número; no reutilices el de la anulada. Puede quedar un hueco en la numeración; eso es preferible a reutilizar un número ya enviado a la AEAT.
Cuando un cliente pide factura completa a partir de un ticket F2 ya emitido: la F3 sustituye la simplificada e identifica al destinatario con NIF.
En Verifct Basic, normalmente una app. Más apps y cupos mayores entran en Verifct Pro (o solicitud de aumento de límite cuando te acerques al tope).
Validan el ciclo F1, F2, rectificativa, sustitución y anulación en entorno de prueba antes de pasar a producción. Los fallos de una prueba concreta se pueden filtrar en Errores.
* El contenido de estas FAQs —incluidas las referencias de carácter jurídico, fiscal, contable y de cumplimiento Verifactu / AEAT— se facilita a título meramente orientativo e informativo, elaborándose con la mayor diligencia y exactitud razonablemente posibles. No constituye asesoramiento profesional vinculante ni sustituye el criterio de un asesor fiscal, mercantil o jurídico cualificado. Worktocloud, S.L. y el servicio Verifactu WorkToCloud declinan toda responsabilidad por errores tipográficos, omisiones, ambigüedades, interpretaciones erróneas o defectos de redacción que pudieran derivar en una ejecución incorrecta del flujo de remisión de registros de facturación, en la omisión de pasos técnicos o procedimentales exigibles, o en cualquier perjuicio directo o indirecto derivado del uso de esta información. El obligado tributario permanece, en todo caso, como único responsable del cumplimiento normativo y de la integridad de los datos transmitidos.
La API vive en https://verifactu.worktocloud.es/api/v1/. Incluye siempre la versión (/v1/) en la ruta. La ruta antigua /verifactu.php/api/v1/… sigue funcionando.
Cada petición debe identificarse con las credenciales de una app de tu panel (Apps). Esas credenciales atan la llamada a tu empresa: solo verás y podrás operar sobre tus facturas, nunca las de otro cliente.
1. Obtén AppId y AppSecret
2. Envíalo en cada petición (elige una forma; ambas son válidas):
curl o Postman.Cabeceras (recomendado)
GET /api/v1/invoices HTTP/1.1 Host: verifactu.worktocloud.es X-App-Id: TU_APP_ID X-App-Secret: TU_APP_SECRET Accept: application/json
Query string
GET https://verifactu.worktocloud.es/api/v1/invoices?AppId=TU_APP_ID&AppSecret=TU_APP_SECRET
Ejemplo curl
curl -sS "https://verifactu.worktocloud.es/api/v1/invoices" \ -H "X-App-Id: TU_APP_ID" \ -H "X-App-Secret: TU_APP_SECRET" \ -H "Accept: application/json"
3. Demo vs real (y la IP)
VF_IP_UNAUTHORIZED (HTTP 401).Si fallan las credenciales verás códigos como VF_INVALID_CREDENTIALS o VF_APP_INACTIVE. Si falta /v1/ en la ruta: VF_API_VERSION_MISSING. El listado completo está en errores globales y en cada endpoint.
Pulsa un endpoint para expandir el detalle justo debajo (vuelve a pulsar para ocultarlo). En las rutas, {número} es el número de factura (p. ej. FAC2026-000001), no el id interno.
Clientes listos para copiar en tu proyecto. Sustituye APP_ID / APP_SECRET por los de tu app. Base canónica: https://verifactu.worktocloud.es/api/v1.
Prueba peticiones y respuestas sin llamar a la API real, sin guardar datos y sin enviar nada a Hacienda.
Pulsa «Simular respuesta» para ver el resultado.
Visión global de Verifactu. Solo visible con StatusUser 3.
Versión de API publicada, textos legales activos y credenciales OAuth hacia WorkToCloud. Vacío = valor de config.local.php.
Desplázate hasta el final del documento para poder aceptarlo.
La IP se ha registrado como pendiente. Hasta validarla, no se aceptarán peticiones desde ella en modo real.
Crea un registro TXT en _verifactu.tu-dominio con el valor:
—
Publica en la raíz del servidor el archivo verifactu-challenge.txt con exactamente este texto:
—
URL recomendada: http://IP/verifactu-challenge.txt. También se acepta en /.well-known/verifactu-challenge.txt.
Cuando esté listo, pulsa Validar DNS o Validar HTTP en el listado de orígenes.
Esta función forma parte de Verifct Pro.
Compara el plan actual con Pro y desbloquea más capacidad cuando lo necesites.
Ideal para empezar y emitir con tranquilidad.
Más apps, diseños, idiomas y margen de API.
La activación comercial de Pro se completará en breve. Mientras tanto puedes revisar las ventajas.