RCV y F29

Sincroniza el registro de compras y ventas del SII y obtén tu declaración mensual de IVA propuesta, lista para verificar antes de presentar.

Qué es el RCV

El Registro de Compras y Ventas es la nómina oficial del SII con todos los DTEs que tu empresa recibió (compras → crédito IVA) y emitió (ventas → débito IVA) en un período. Notta lo sincroniza desde el SII con el certificado digital que ya cargaste para firmar tus DTEs (no necesitas clave tributaria) y lo guarda como snapshot consultable por período. El RCV puede tardar en reflejar documentos recientes; si falta algo que esperabas ver, fuerza un sync con force: true.

El RCV reemplazó a los Libros Electrónicos de Compra y Venta (IECV) a partir del período agosto de 2017 (Res. Ex. SII N°61 y N°68 de 2017): si eres emisor electrónico autorizado, ya no envías libros mensuales al SII. La carta de autorización del SII todavía incluye un párrafo que los exige: es texto heredado de una plantilla anterior a 2017.

Qué es el F29

El Formulario 29 es la Declaración Mensual de IVA. Notta va a calcular el F29 propuesto del período a partir de los snapshots RCV, todavía no está disponible, ver el estado más abajo:

Línea	Cálculo
Débito fiscal	Suma del IVA de las ventas afectas del período (las exentas 34/41 no aportan)
Crédito fiscal	Suma del IVA de las compras afectas
Retenciones	Retenciones de BHE percibidas en el período
Neto a pagar (Línea 89)	`max(0, débito − crédito − retenciones)`
Crédito remanente (Línea 77)	El excedente, cuando el saldo queda a tu favor

El F29 de Notta es read-only: lo verificas contra la propuesta del SII y presentas la declaración en el portal del SII.

Endpoints

Canal	Operación	Para qué
API	`POST /api/v1/rcv`	Sincroniza el snapshot de un período: body `{ rut, periodo, type?, force? }`
API	`GET /api/v1/rcv?periodo=YYYY-MM`	Lista los snapshots del período (filtros `rut` y `type`, orden `sort`/`dir`)
API	`GET /api/v1/rcv/documents?type=issued`	El registro documento por documento, tipado y paginado

type acepta received, issued o both (default both). Sync de ejemplo:

curl -X POST https://app.notta.cl/api/v1/rcv \
  -H "Authorization: Bearer ntt_cert_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "rut": "76123456-0", "periodo": "2026-04", "type": "both" }'

La respuesta es { "snapshot_id": "…", "from_cache": false }.

Leer el registro documento por documento

GET /rcv devuelve el snapshot: el parsed_json con las filas tal como las manda el SII. Sirve para auditar, pero trabajar contra él significa parsear nombres de campo del Servicio que ni siquiera son estables. GET /rcv/documents es la lectura tipada, una fila por documento, con el vocabulario de Notta:

curl "https://app.notta.cl/api/v1/rcv/documents?type=issued&periodo=2026-04&limit=100" \
  -H "Authorization: Bearer ntt_prod_..."

Query param	Requerido	Descripción
`type`	sí	`issued` (ventas) o `received` (compras)
`periodo`	no	`YYYY-MM`. Omitirlo devuelve todos los períodos
`estado`	no	Sección del registro. Default `registro`; `all` trae las cuatro
`limit`	no	Default 100, máx 500
`cursor`	no	El `next_cursor` de la página anterior

La respuesta es { data, total, next_cursor, synced_at }. total es el universo que matchea el filtro, no el tamaño de la página: recorres mientras next_cursor no sea null y verificas que lo leído calce con total. La paginación es keyset sobre el id, que es estable entre re-sincronizaciones: un sync nuestro a mitad de tu recorrido no te reordena lo ya visto.

synced_at antes de interpretar total. Es la última vez que bajamos el registro del SII para ese filtro, o null si nunca se sincronizó. Sin mirarlo, total: 0 tiene dos lecturas opuestas («este período no tuvo documentos» y «todavía no tenemos los datos») y para quien concilia una cierra el mes y la otra es una alarma.

Para recorrer un período completo, usa `estado=all`

El registro del SII tiene cuatro secciones: registro (lo asentado), pendiente, no_incluir y reclamado. El default devuelve solo la primera.

Y hay una segunda razón, menos obvia: estado es mutable. Un documento migra de sección y nuestro sync lo refresca en la misma fila, conservando su id. Si recorres con estado=registro y un sync corre a mitad de tu recorrido, un documento que estaba en pendiente puede pasar a registro detrás de tu cursor: nunca te lo servimos, pero total, que se recalcula en cada página, sí lo cuenta. Terminas con filas_leídas = total - 1 y sin saber cuál falta.

Recorre con ?estado=all, que es un filtro invariante, y clasifica por el campo estado de cada fila. Si solo necesitas una foto y no un recorrido verificable, el default está bien.

Una última cosa sobre lo que filas_leídas === total garantiza: que leíste todo lo que nosotros tenemos, no todo lo que el SII tiene hoy. Un documento que desaparece del registro del SII conserva aquí su último estado conocido: no lo borramos.

Tres campos que no están en el snapshot crudo y resuelven casos concretos:

evento_receptor: el código con que el SII reporta lo que hizo la contraparte, no solo su glosa. Llegan cuatro, todos de una letra: R (reclamado por el receptor), C (recibo otorgado), A (no reclamado en plazo, que aparece solo en compras) y P, que no es un evento del receptor: significa que el emisor declaró la operación al contado, y sobre esas el SII no registra acuse ni reclamo. Ramificar por el código y no por la glosa, que es texto libre, es lo que separa un reclamo de una forma de pago. Para entender qué significa un reclamo sobre una venta tuya, el plazo que corre y por qué no se puede revertir: Reclamo del receptor.
referencia_tipo / referencia_folio: el documento al que esa fila hace referencia. No equivale a «este documento corrige a otro»: una factura también referencia, y de hecho lo hace (facturas 33 que apuntan a la guía 52 que consolidan, o a documentos de papel). Para saber si es una corrección mira document_type: solo 56 y 61 corrigen. Y no asumas que el referenciado es una factura afecta: hay referencias reales a exentas (34), boletas (39) y a otras notas de crédito (61); enlazar solo por folio, sin el tipo, cruza secuencias distintas.
dte_id / documento_disponible: si el documento también existe en Notta y se puede bajar con /dtes/{dte_id}/pdf, /xml o /pdf-url. dte_id en null significa que la fila vive solo en el registro del SII, que guarda el asiento y no el documento.

Los montos son enteros y total_amount es el total del documento según el SII. En documentos con retención o impuestos adicionales (por ejemplo una Factura de Compra 46) net_amount + exempt_amount + vat_amount no suma total_amount: esos tributos no tienen columna propia aquí, así que el total es el número con el que se cuadra.

Estado actual

El sync y la consulta del RCV (/api/v1/rcv) funcionan hoy con tu API key, y el servidor MCP puede leer tu registro (listRcv y listRcvDocuments, dos de las 24 operaciones de su catálogo).

El F29 todavía no está disponible en ninguna superficie: no tiene endpoint en /api/v1, no está en el dashboard y el MCP no lo cubre. La tabla de arriba describe el cálculo que Notta va a exponer, no algo que puedas consultar hoy. Mientras tanto, el F29 propuesto lo ves en el portal del SII, y la presentación siempre es manual.

Próximos pasos

Referencia de la API: el resto de los endpoints de /api/v1 con sus shapes.
BHE: las boletas de honorarios cuyas retenciones alimentan el F29.
Notta para agentes: llms.txt, OpenAPI y MCP para operar Notta desde un LLM.
Pasa a producción: el camino para que estos números tengan valor tributario real.