Alcance y limitaciones

Toda plataforma tiene fronteras. Una frontera que puedes leer antes de integrar es una decisión de diseño; una que descubres en producción es un defecto. Esta página es la única lista canónica — ninguna otra guía mantiene la suya.

Cada fila declara el escenario, su estado y el workaround: la alternativa disponible hoy, o una declaración explícita de que no la hay. Hay exactamente dos estados, porque una tercera categoría difusa es lo que convierte páginas como esta en mero adorno:

Por diseño — no lo vamos a construir. La alternativa está aquí.
En roadmap — aplazado, no descartado.

Verificado el 3 de octubre de 2026 contra la v1 de la API. Una fila cuyo escenario pase a estar soportado se retira en el mismo cambio que lo implementa, en lugar de quedarse ahí como limitación obsoleta.

Limitaciones verificadas contra el código

Escenario	Estado	Workaround
Autofactura — el destinatario expide la factura en nombre del proveedor	Por diseño	No está modelada. El proveedor expide su propia factura. Si operas ambas partes, emítela desde la cuenta del proveedor.
Factura expedida por un tercero	Por diseño	El campo AEAT de expedición por tercero no se emite. Una asesoría que alcanza el NIF de un cliente, por un acceso cedido o como proveedor de una cuenta gestionada, emite desde esa empresa nombrándola en el segmento de empresa de la ruta; la factura se declara como expedida por la propia empresa.
Multidivisa	Por diseño	El contrato v1 expone el euro, fijo: `currency` vale siempre `EUR` y no existe columna de divisa. Filtrar un listado por cualquier otra divisa devuelve una página vacía, no un error. Escribe los documentos públicos en EUR; los conectores de tiendas pueden convertir los pedidos entrantes a EUR.
TicketBAI / Batuz (País Vasco)	Por diseño	Sin alternativa dentro de Factuarea. Los sistemas forales vascos usan esquemas, certificados y endpoints distintos, y exigen su propio software homologado. Las empresas con domicilio fiscal vasco reciben el aviso durante el onboarding.
Inversión del sujeto pasivo, y cualquier régimen de operación de cabecera, declarados por la API	Por diseño	El `operation_regime` de cabecera es de solo lectura en la v1 —ni la creación ni la actualización lo aceptan—, así que toda factura creada por la API nace en régimen general y se califica `S1`. La exención y la no sujeción se declaran por línea con `lines[].exemption_reason`, pero la inversión del sujeto pasivo es la calificación `S2` y no tiene equivalente de línea: emite esas facturas desde el panel. Ver Clientes internacionales.
Suplidos fuera de la factura emitida — presupuestos, proformas, albaranes, gastos, plantillas de recurrentes	Por diseño	Solo la factura emitida modela los suplidos. Incluye el importe como línea ordinaria en el documento previo, y fija `line_type` en la factura resultante mientras siga en borrador — la operación de actualización lo acepta.
Suplidos en el XML de Facturae y UBL — el importe a pagar del XML es el total fiscal, no el importe debido	En roadmap	La base imponible y las cuotas salen correctas —el suplido está bien excluido—, pero el importe a pagar se queda corto por ese importe y ningún elemento del XML transporta la diferencia. No remitas por FACe una factura con líneas de suplido mientras no se mapee el bloque nativo de Facturae 3.2.2: factura el suplido fuera de ese canal.
Suplidos en las cifras agregadas de cartera — el `pending_amount` de `GET /v1/companies/{company}/invoices/stats`, el informe de aging y el de mayores deudores	Por diseño	Esos agregados miden volumen facturado, la misma magnitud que declara la declaración anual de operaciones con terceros, y tampoco han restado nunca los cobros parciales. Para el importe realmente debido, lee el `pending_amount` de cada factura, que sí mide contra el importe a pagar.

Diferencias deliberadas con otras plataformas

Son decisiones de producto conscientes, no huecos. Cada una existe porque la alternativa que elegimos es mejor para quien integra que el patrón que se nos pide.

Escenario	Estado	Workaround
Paginación por desplazamiento con número de páginas y salto a la página N	Por diseño	Paginación por cursor al estilo de Stripe: `limit` con límites validados, más `starting_after` o `ending_before` (mutuamente excluyentes). Las respuestas llevan `has_more` y `next_cursor`, y `next_cursor` vale `null` cuando `has_more` es falso. Ver Paginación.
Envelope de error dual permanente — nuestro envelope y RFC 9457 en el mismo cuerpo, siempre	Por diseño	Negociación de contenido. `Accept: application/problem+json` devuelve RFC 9457 puro; cualquier otro caso —`application/json`, `/`, sin cabecera `Accept`— devuelve nuestro envelope. Ver Errores.
Atomicidad total en la creación masiva — una fila mala rechaza el lote entero	Por diseño	Éxito parcial. La respuesta lleva `{dry_run, total, successful, failed, results, failures}`, donde cada fallo identifica su fila por un `index` que empieza en cero, con su propio código de error. Importa 480 de 500 y arregla las 20. Ver Operaciones masivas.
Totales de línea obligatorios en la petición (`line_total`, `taxable_base`)	Por diseño	`line_total` es una suma de control opcional verificada: se compara con el total calculado con una tolerancia de un céntimo y se descarta — nunca se persiste, nunca se devuelve. No tienes que replicar nuestro motor de cálculo. Ver Suplidos.
Una cabecera de petición que cambia la empresa activa — una credencial más un header de perfil por petición	Por diseño	La empresa viaja en la ruta. La empresa efectiva es el segmento `{company}` de `/v1/companies/{company}/…`, y lo que alcanza una credencial es el conjunto de NIF dentro de su ámbito —los propios, los cedidos a su cuenta y los de las cuentas que gestiona—, nunca un perfil que se activa: ver qué NIF alcanza una credencial. La cabecera `X-Active-Profile` está retirada: una petición que la envíe se rechaza con `400 parameter_unknown`, subcódigo `retired_active_profile_header`, sea cual sea su valor. Ver Alcanzar un NIF por el segmento de empresa.
Sustituir facturas simplificadas en dos pasos — una rectificativa más una factura completa nueva	Por diseño	Un solo paso nativo: `POST /v1/companies/{company}/invoices/substitute-simplified` emite la factura sustitutiva agregando varias simplificadas. Ver Facturas simplificadas o completas.
SDK de Python	En roadmap	Genera un cliente a partir del documento OpenAPI publicado, o usa los SDK de TypeScript o PHP, el CLI o el servidor MCP.

Qué NIF alcanza una credencial

Una credencial opera sobre un NIF nombrándolo en el segmento {company} de la ruta, y alcanza los NIF que están dentro de su ámbito de NIF. Vienen de tres sitios:

Su propia cuenta. Los NIF de la cuenta a la que pertenece la credencial.
Un acceso cedido. Los NIF que otra cuenta cedió a su cuenta, todos o una lista, con el nivel view u operate.
Una cuenta gestionada. Los NIF de las cuentas gestionadas que su cuenta provisionó, mientras la gestión siga vigente y el nivel no sea none.

Una clave nunca alcanza más de lo que nombra su ámbito, y su ámbito nunca excede lo que alcanza su cuenta. Un NIF que la credencial no alcanza, o que alcanza con el nivel none, responde 404 profile_not_found. Sobre un NIF alcanzado por una relación entre cuentas se aplican dos límites, y ninguno cambia ningún dato:

Las capacidades de la cuenta que posee el NIF se quedan con ella. Las operaciones que pertenecen a la cuenta dueña del NIF —la facturación, los endpoints de webhook de empresa, los registros de peticiones y los eventos de empresa, el uso de las automatizaciones y las escrituras de sus credenciales de pago— responden 403 forbidden_action antes de leer o cambiar nada, con cualquiera de los dos niveles. El equipo, las invitaciones, la titularidad, las claves de API, la cartera de NIF y los traspasos de esa cuenta viven bajo /v1/accounts/{account}/…, donde {account} tiene que ser tu propia cuenta: otra responde 404 account_not_found.
view lee. Con el nivel view, toda escritura sobre el NIF responde 403 company_read_only. Con operate puedes escribir, salvo lo que el primer límite deja con la cuenta dueña.

Lo que se queda en la cuenta cedente enumera las operaciones que se quedan con la cuenta dueña, y Qué rutas de {account} aceptan una cuenta gestionada las rutas de {account} que la aceptan.

Lo que el modelo de cuentas deja fuera, a propósito

El modelo de cuentas deja algunas decisiones en manos de una persona y algunas superficies fuera de la API. Cada fila de abajo es deliberada, y su workaround es la forma de resolver el caso.

Escenario	Estado	Workaround
Gestionar un acceso cedido por la API o el servidor MCP — ceder, aceptar, rechazar, cambiar, reenviar, revocar o renunciar a un acceso entre cuentas	Por diseño	La aplicación web. Lo decide y lo confirma allí una persona de cada cuenta, de modo que una clave filtrada no puede abrir los NIF de su cuenta a otra cuenta. La cuenta cedente usa Ajustes → Accesos a mi cuenta y la receptora, Ajustes → Accesos recibidos. Lo que la API sí da es el alcance de un acceso cedido: ver qué NIF alcanza una credencial y Ceder, cambiar y revocar en la aplicación web.
El lado del cliente de una cuenta gestionada por la API — reclamar la cuenta, subir o bajar el nivel del proveedor, terminar la gestión y asumir el pago	Por diseño	El cliente lo hace en la aplicación web. Una credencial del proveedor no puede decidir por el titular. Tu lado, el del proveedor, está completo por la API y por el servidor MCP: cambia tu nivel con `PATCH /v1/accounts/{account}/access-level`, termina la gestión con `DELETE /v1/accounts/{account}/management` y reemite el vale. Ver El lado del cliente es de la app.
Importación masiva mediante una herramienta MCP	Por diseño	La API REST o la importación de la aplicación web. Las tres operaciones son privilegiadas y la importación lee dos ficheros subidos, que el servidor MCP no transporta. Desde un agente, provisiona las cuentas de una en una con la herramienta `provision_managed_account`, que refleja `POST /v1/accounts`. Ver Dos cosas que la importación no hace, por diseño.
Webhooks y registros de peticiones de cuenta más allá de tu propia cuenta, o por OAuth — administrar los de una cuenta gestionada o cedente, o usar sus herramientas MCP desde una conexión OAuth	Por diseño	Tu propia cuenta, con una clave de API. `{account}` es siempre la cuenta de la credencial. Un proveedor de cuentas sigue los eventos de las cuentas que gestiona en su propio endpoint con el filtro `managed`. Las doce herramientas MCP de webhooks y de registros de peticiones de cuenta funcionan solo con una clave de API: una conexión por OAuth no las lista ni las llama. Ver Cuatro diferencias que no son de nombre.
Un endpoint de webhook de empresa sobre un NIF alcanzado por una relación	Por diseño	Un endpoint de cuenta. Las once operaciones de `…/webhook-endpoints` y las dos de `…/request-logs` sobre un NIF de otra cuenta, cedido o gestionado, responden `403 forbidden_action` porque pertenecen a la cuenta que lo posee. Para seguir los NIF de las cuentas que gestionas, crea un endpoint de cuenta con el filtro `managed` o `all`. Un acceso cedido no se sigue con webhooks en el lado receptor: la cuenta cedente recibe los eventos de sus propios NIF. Ver Endpoints y registros de empresa sobre un NIF alcanzado por una relación.
El historial de correos de una cuenta entera — `GET /v1/accounts/{account}/emails`, su detalle y sus indicadores	Por diseño	Léelo NIF por NIF. El historial vive en el eje de empresa, con el scope `emails:read` y dentro del ámbito de la credencial: `GET /v1/companies/{company}/emails`, su detalle y sus indicadores. Las tres rutas de cuenta no existen.
Series de documentos en la importación masiva — una columna o una opción para crear o elegir la numeración de cada NIF importado	Por diseño	Crea las series con el eje de empresa. La importación da de alta cuentas y NIF, no su numeración: su plantilla tiene un conjunto cerrado de columnas y ninguna es una serie. Después, `POST /v1/companies/{company}/series/bootstrap` crea en una llamada las series por defecto que faltan con `series:write`, y `issuing-readiness` informa de `no_default_series` mientras falte una. Ver Dos cosas que la importación no hace, por diseño.
El asesor externo por la API o el servidor MCP, en un plan sin gestión de usuarios	Por diseño	La aplicación web, en cualquier plan. La gestión del equipo por la API y el servidor MCP pertenece al módulo `user_management`, que incluyen `empresario` y `enterprise` y no `emprendedor`: sin él los scopes `members:` e `invitations:` no se pueden asignar. La aplicación web invita al asesor, edita sus grants, reenvía o cancela la invitación, retira al asesor y quita la marca en cualquier plan. Con el módulo, un miembro existente se marca o se desmarca con `external_advisor` en `PATCH /v1/accounts/{account}/members/{member}`. Ver Planes sin gestión de usuarios.

Capacidades que puedes dar por ausentes

Ocho cosas que Factuarea sí hace y que quien llega de otras plataformas espera habitualmente no encontrar:

Capacidad	Dónde
Factura sustitutiva de simplificadas, en una sola llamada — agregar varios tiques en una factura completa sin rectificativa previa	Facturas simplificadas o completas · `POST /v1/companies/{company}/invoices/substitute-simplified`
Subsanación de registros VeriFactu aceptados o rechazados, expuesta en la API pública — corregir un registro con uno nuevo, sin anular la factura y sin editar el original	Subsanación de registros VeriFactu · `POST /v1/companies/{company}/verifactu/records/{record}/subsanar`
Remisión por un tercero — Factuarea remite los registros con su propio certificado al amparo de un apoderamiento (o del anexo I firmado de la colaboración social), de modo que la empresa no entrega su certificado	Alta automática en VeriFactu · `POST /v1/companies/{company}/verifactu/representation`
Cobro desatendido en una llamada idempotente — una factura simplificada ya cobrada con su QR VERI*FACTU, que se puede reenviar con seguridad días después por `external_id`	Facturación desde terminales desatendidos · `POST /v1/companies/{company}/invoices`
Rectificativa por diferencias con base imponible negativa — la forma fiscalmente correcta de expresar un abono	Facturas rectificativas
Catálogo fiscal AEAT consultable por la API — regímenes indirectos, regímenes de operación, causas de exención con su artículo de la LIVA, tipos de retención y los pares legales de IVA y recargo, en tres idiomas	Claves de régimen · `GET /v1/tax-catalog`
Catálogo de producto medido — unidades UNECE, presentaciones fijas/variables, variantes con stock propio opcional y ofertas de proveedor	Catálogo de productos
Tarifas por cliente y documento — precios a cuatro decimales, precedencia estable variante/presentación y repricing explícito de borradores	Tarifas · `POST /v1/companies/{company}/price-lists/resolve`

Ninguna de ellas está anunciada ni en desarrollo: las ocho son operaciones vivas hoy.

Dónde vive el razonamiento fiscal

Esta página lista fronteras. Las guías que explican las reglas que hay detrás:

Estados de envío VeriFactu

El ciclo de vida del registro, reintento y subsanación.

Facturas rectificativas

R1–R5, sustitución frente a diferencias.

Claves de régimen

Calificación de cabecera y catálogo de régimen por línea.

Impuestos territoriales

IVA, IGIC e IPSI.

Suplidos

Importes pagados por cuenta del cliente.

Clientes internacionales

Identificación alternativa y mapa de escenarios.

Trazabilidad

Esta página documenta la ausencia de comportamiento, algo que ninguna regla de negocio puede afirmar. Sus filas se anclan, por tanto, de forma distinta a las demás guías fiscales: a un punto verificado del código, a la decisión registrada para la plataforma o —cuando sí existe una regla de negocio— a esa regla.

Limitaciones verificadas contra el código:

Fila	Anclaje
Autofactura	No existe esa capacidad en el dominio. Las únicas apariciones del concepto son la factura que Factuarea emite a sus propios suscriptores y la comprobación de la empresa del sistema — ninguna de las dos es una capacidad de la API.
Factura expedida por un tercero	El campo AEAT de expedición por tercero no se emite nunca; cero apariciones en el código de la aplicación.
Multidivisa	`InvoiceV1Resource` devuelve el literal `'EUR'`, y el repositorio de lectura de la v1 documenta que cualquier otra divisa produce una página vacía.
TicketBAI / Batuz	`BR-VFC-019` — deliberadamente fuera del alcance del contexto VeriFactu.
Inversión del sujeto pasivo por la API	Ninguna petición de la v1 acepta `operation_regime`; el recurso de factura lo devuelve de solo lectura. `BR-VFC-029` deriva la calificación de ese régimen de cabecera, y `BR-INV-032` acota el catálogo de línea a causas de exención y no sujeción, sin códigos `S`.
Suplidos fuera de la factura emitida	`BR-INV-037` y el objeto de valor del tipo de línea, que declara que solo la factura emitida modela los suplidos; `BR-INV-040` para la restricción de la factura simplificada.
Suplidos en el XML de Facturae y UBL	El edge case de aviso de `BR-INV-042`, que deja registrado que el importe a pagar de ambos documentos es el total fiscal y que el bloque nativo de Facturae 3.2.2 aún no está mapeado.
Suplidos en las cifras agregadas de cartera	El edge case de `BR-INV-045`, que deja registrado que los agregados miden volumen facturado y que se dejan midiendo eso a propósito.

Diferencias deliberadas: ancladas a los componentes HTTP compartidos que implementan la alternativa —la paginación por cursor, el negociador de contenido de errores, el recurso de éxito parcial de las operaciones masivas—, a BR-INV-044 para la suma de control opcional de línea, y a BR-INV-015 y BR-INV-016 para la sustitución en un solo paso. La fila del SDK de Python refleja una decisión registrada de planificarlo aparte cuando la especificación se estabilice: está aplazado, no descartado, y por eso su estado es En roadmap y no Por diseño. La cabecera de perfil retirada se ancla al middleware de la v1 que la rechaza por presencia, antes de que corra ningún handler, y a su rechazo catalogado 400 · parameter_unknown · retired_active_profile_header.

Alcance de una credencial: BR-ACC-181 para el segmento de empresa como único mecanismo de empresa efectiva, que alcanza también los NIF de las relaciones vigentes dentro del ámbito, BR-ACC-180 para el ámbito que nunca excede lo que alcanza la cuenta, BR-ACC-191 para el inventario cerrado de operaciones del eje de empresa que responden 403 forbidden_action, BR-ACC-153 para lo que significan operate y view sobre un NIF alcanzado por una relación, y BR-ACC-043 para el 403 company_read_only de view.

Exclusiones del modelo de cuentas:

Fila	Anclaje
Gestionar un acceso cedido por la API o el servidor MCP	`BR-ACC-199`: una lista cerrada de doce nombres de ruta, con su razón como clave, y un gate que comprueba que cada una existe y que ninguna ruta v1 ni herramienta MCP la refleja. `BR-ACC-155` para lo que hace cada lado en la aplicación web.
El lado del cliente de una cuenta gestionada por la API	`BR-ACC-199`: siete nombres de ruta del lado del titular, en el mismo gate. `BR-ACC-164` y `BR-ACC-165` para el nivel y el fin de la gestión, y `BR-ACC-194` para el lado del proveedor, que sí tiene sus rutas y herramientas.
Importación masiva mediante una herramienta MCP	`BR-ACC-200`, que deja registrado que la importación no tiene herramienta, y la exclusión declarada de las tres operaciones `managed_accounts.imports.*` en el test de paridad v1 ↔ MCP.
Webhooks y registros de peticiones de cuenta más allá de tu propia cuenta, o por OAuth	`BR-ACC-230` para la capacidad de la cuenta comprobada en cada petición, y `BR-ACC-233` para las doce herramientas que rechazan el canal OAuth una a una.
Un endpoint de webhook de empresa sobre un NIF alcanzado por una relación	`BR-ACC-234`, dentro del inventario cerrado de `BR-ACC-191`.
El historial de correos de una cuenta entera	`BR-ACC-235`: las tres rutas se declaran como no expuestas en el gate de paridad de ejes, y un test falla si alguna aparece en el enrutador.
Series de documentos en la importación masiva	El conjunto cerrado de columnas de la plantilla de importación, ninguna de las cuales es una serie, y la petición de importación, que no tiene ninguna opción de series.
El asesor externo por la API o el servidor MCP, en un plan sin gestión de usuarios	`BR-ACC-107`: la aplicación web gestiona al asesor en cualquier plan, mientras que los scopes de equipo de la API siguen al módulo `user_management`. `BR-ACC-199` enumera las diez rutas que existen solo en la aplicación web.

Capacidades: cada una se ancla a la ruta viva que la materializa — public-api.v1.invoices.substitute_simplified, public-api.v1.verifactu.records.subsanar, public-api.v1.verifactu.representation.register, public-api.v1.invoices.create y public-api.v1.tax-catalog.show — más BR-VFC-042 para la remisión por un tercero, BR-VFC-046 para la subsanación como alta nueva, BR-VFC-033 para la base imponible negativa y BR-TAX-028 para el catálogo fiscal, BR-PRD-026…BR-PRD-030 para el catálogo medido y BR-PRI-001…BR-PRI-004 para las tarifas.

Pedidos en otras divisas

Los importes de documentos públicos siguen en EUR. Los conectores de comercio electrónico pueden importar un pedido en otra divisa y convertirlo a EUR; esto no añade escrituras de documentos en cualquier moneda a v1. Se siguen aplicando las comprobaciones de identificación y fiscalidad; la falta de tipo de cambio o de datos admitidos del comprador produce un resultado observable de integración. Consulta tiendas.