DeRE - Intro y Accounts API

Cargá el plan de cuentas de tu empresa mediante la Accounts API para que Brinta pueda generar y validar el evento D-1011 de la DeRE (Declaração de Regimes Específicos).

La DeRE es la obligación accesoria del IBS y la CBS para regímenes específicos. El D-1011 (Plano Geral de Contas Comentado o PGCC) incluye el plan de cuentas y la clasificación tributaria de cada cuenta. Brinta recibe las cuentas, arma el evento, lo valida y lo transmite a la Receita. Las cuentas también sirven de referencia para los eventos mensuales: toda cuenta que aparezca en el balancete debe existir y estar vigente en el plan.

Esta guía cubre solo la carga del plan de cuentas por la Accounts API. No cubre saldos, asientos contables ni operaciones transaccionales. Para estas últimas, consultá DeRE: envío de transacciones a Brinta.

Antes de empezar

1. Da de alta la empresa declarante en Brinta con su CNPJ. Brinta usa el CNPJ raíz para identificarla en la DeRE.
2. Confirmá con Brinta la configuración de la declaración DeRE: el D-1011 se genera actualmente para Servicios Financieros, con plan referencial COSIF. El plan referencial del encabezado (planoCtaRef) y la frecuencia de cierre (freqEncerr) se configuran en la declaración, no se envían por la Accounts API.
3. Obtené el token en el dashboard, en Company Management › API & Integrations.
4. Pedí a tu equipo tributario la relación de cada cuenta con su codTrib (para cuentas analíticas) y con su cuenta COSIF (para todas las cuentas). La integración transporta estos datos; no decide la clasificación tributaria.
5. Identificá las cuentas analíticas que tienen más de un codTrib y desdoblalas antes de cargar el plan.

Pendiente de validar con Brinta: el generador admite SPED y PREVIC, pero esos grupos no están disponibles hoy en la plataforma. ANS y SUSEP no están soportados para generar el D-1011.

Cargar el plan de cuentas

1. Prepará los datos. Para cada cuenta definí tipo, nivel, padre, naturaleza contable, naturaleza del saldo, COSIF y vigencia. Para cada cuenta analítica agregá un único codTrib y el indicador de ISS.
2. Desdoblá las cuentas mixtas. Convertí cada cuenta analítica con más de un codTrib en una cuenta original sintética (split_code: "000") y una hija analítica por codTrib ("001", "002", etc.). Las hijas usan la misma cuenta COSIF que la original.
3. Ordená la carga por nivel. Creá las cuentas de nivel 1 antes de las de nivel 2 y continuá hasta las hojas; el padre debe existir, ser sintético y estar activo antes de crear una hija.
4. Enviá un POST /accounts por cuenta. Usá Authorization: Bearer <token> y Content-Type: application/json. El endpoint de producción es https://api.brinta.com/accounts.
5. Comprobá cada resultado. Una respuesta 200 indica que la cuenta se guardó, no que ya pasó la validación DeRE. Ante un 4xx, corregí la solicitud. Ante un 500, consultá la cuenta antes de reintentar: algunos errores pueden ocurrir después de que se creó.
6. Verificá las cuentas con GET /accounts. Filtrá por account_external_id e identificador de empresa. Validá además las reglas de DeRE de esta guía antes de pedir la generación del D-1011.
7. Avisá a Brinta cuando termines la carga para que genere el D-1011. Un evento con errores no se transmite hasta que se corrijan.

Cuando cambie el plan, creá las cuentas nuevas o los nuevos desdoblamientos con POST /accounts. La Accounts API no permite modificar una cuenta existente: los cambios en cuentas ya creadas se hacen desde el dashboard. Brinta genera una nueva versión del D-1011 con la nueva vigencia.

Identificar la empresa y consultar una cuenta

Enviá exactamente uno de estos campos en el body de POST, o como parámetro de consulta en GET:

Podés enviar parent_company_id o parent_company_external_id para verificar que la empresa pertenezca a ese grupo. Un token solo puede leer y escribir cuentas de empresas de su propio grupo.

curl "https://api.brinta.com/accounts?account_external_id=1101000&company_account_external_id=CLI-98765" \
  -H "Authorization: Bearer $BRINTA_TOKEN"

Ejemplo de respuesta 200 según el esquema público:

{
  "account_external_id": "1101000",
  "company_id": "7b1e2c4a-0d3f-4e5a-9b8c-1a2b3c4d5e6f",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Caixa e equivalentes de caixa",
  "description": "Disponibilidades em caixa e em contas de liquidez imediata",
  "type": "A",
  "level": 3,
  "order_id": 3,
  "nature": 1,
  "sub_nature": "D",
  "parent_account": "11000",
  "split_code": "000",
  "status": "ACTIVE",
  "start_date": "2026-10-01T00:00:00Z",
  "valid_from": "2026-10-01T00:00:00Z",
  "centers": []
}

Pendiente de validar: si la respuesta también incluye account_mappings y code_mappings; no aparecen en el esquema público usado para este ejemplo.

Entender los datos de una cuenta

Una cuenta sintética agrupa otras cuentas y no recibe saldo; una cuenta analítica es una hoja del árbol y recibe saldo. La API recibe una llamada POST por cuenta. Para el D-1011, cada una se convierte en una infoConta.

Campos de POST /accounts

La API puede crear una cuenta aunque le falten campos necesarios para el D-1011. Validalos antes de cargar el plan: la generación del evento detecta estos errores y bloquea su transmisión.

Tipo y naturaleza

Enviá S para cuentas sintéticas y A para analíticas. La API guarda otros textos en type porque el campo sirve a otras obligaciones; para la DeRE Brinta reconoce S, A, SYNTHETIC y ANALYTIC, y deduce el tipo desde la jerarquía si recibe otro valor. Usá S y A para evitar ambigüedades.

nature indica el grupo contable (codNat en D-1011); sub_nature indica el lado habitual del saldo (natCta). La API acepta otros enteros en nature, pero DeRE exige de 1 a 5. En sub_nature, no envíes vacío ni null: la API solo acepta C, D o V. Brinta advierte si el primer dígito de codTrib no es coherente con nature: 1 activo, 2 pasivo o patrimonio neto, 3 receita, 4 despesa.

Pendiente de validar: cómo conviven los valores de nature exigidos por DeRE con los de ECD cuando la empresa presenta ambas obligaciones.

Código y jerarquía

El código completo (cCta) se forma, según esta guía, concatenando el código interno y split_code, sin puntos ni guiones; por ejemplo 1101 + 000 = 1101000. parent_account referencia el código de una cuenta ya creada en la misma empresa, sintética y activa. Las cuentas de nivel 1 no tienen padre.

Pendiente de validar antes de usar los ejemplos en producción: si account_external_id y parent_account deben contener el código completo o el interno. Los ejemplos usan el código guardado de las cuentas DeRE existentes, pero los códigos de cuentas superiores (1000, 11000) no ilustran de forma uniforme la regla de concatenación. Acordá el esquema de códigos con Brinta antes de cargar el plan.

Vigencia y correspondencias

valid_from es el inicio de vigencia (iniVig) y debe reflejar cuándo comenzó a usarse la cuenta. Enviá valid_until (fimVig) solo si dejó de usarse; el fin no puede preceder al inicio. Si omitís start_date, la API toma valid_from y viceversa.

{
  "account_mappings": [
    { "group": "CodTrib IBS/CBS - DeRe", "account": "118915099" },
    { "group": "COSIF", "account": "1.1.1.10.00.00-8" }
  ],
  "code_mappings": [
    { "type": "dere_ind_trib_iss", "value": "0" }
  ]
}

Enviá un solo codTrib por cuenta analítica: nueve dígitos, sin cero inicial y existente en la Tabla 11. Las sintéticas no llevan codTrib ni indicador de ISS, pero todas las cuentas llevan COSIF. Para el indicador de ISS, enviá 1 si la cuenta está sujeta a ISS o 0 si no. La API rechaza grupos o cuentas inexistentes, grupos repetidos y más cuentas mapeadas de las que admite el grupo.

Pendiente de validar: si COSIF debe enviarse exactamente con puntos y guion como figura en el plan. También queda pendiente el indicador natVApur del D-1101; Brinta orienta su envío durante la implementación.

Del JSON al D-1011

Brinta genera el resto: CNPJ raíz (nrInsc), encabezado, período de vigencia del evento, orden de las cuentas, identificador y firma. Otros campos de Accounts API, como name_alt, account_alt, hierarchy_code y centers, no entran en el D-1011.

Ejemplos de carga

Este plan ilustrativo incluye seis cuentas en la tabla y presupone que 71000 y sus antecesoras ya se cargaron. Las cuentas COSIF y los codTrib proporcionados son reales; la clasificación de cada cuenta es ilustrativa. Confirmá el esquema de códigos antes de enviar estos ejemplos.

1. Crear una cuenta sintética de nivel 1

Definí BRINTA_TOKEN con el token del dashboard y enviá:

curl -X POST https://api.brinta.com/accounts \
  -H "Authorization: Bearer $BRINTA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "account_external_id": "1000",
    "company_account_external_id": "CLI-98765",
    "location": "BR",
    "name": "Ativo",
    "description": "Ativo total",
    "type": "S",
    "level": 1,
    "order_id": 1,
    "nature": 1,
    "sub_nature": "D",
    "split_code": "000",
    "valid_from": "2026-10-01T00:00:00Z",
    "account_mappings": [
      { "group": "COSIF", "account": "1.0.0.00.00.00-9" }
    ]
  }'

Esperá 200 para confirmar que la cuenta se guardó. Una sintética no lleva codTrib ni ISS, pero sí COSIF. Si recibís 4xx, revisá el error y corregí la solicitud; si recibís 500, consultá por su código antes de reintentar.

2. Crear la sintética intermedia

Creá 11000 después de 1000:

{
  "account_external_id": "11000",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Disponibilidades",
  "description": "Disponibilidades",
  "type": "S",
  "level": 2,
  "order_id": 2,
  "nature": 1,
  "sub_nature": "D",
  "parent_account": "1000",
  "split_code": "000",
  "valid_from": "2026-10-01T00:00:00Z",
  "account_mappings": [
    { "group": "COSIF", "account": "1.1.0.00.00.00-2" }
  ]
}

Enviá este JSON en el body de POST https://api.brinta.com/accounts con los encabezados del ejemplo anterior. La respuesta esperada es 200; verificá luego 11000 con GET /accounts antes de crear su hija.

3. Crear una analítica

Creá 1101000 después de 11000. Agregá codTrib e indicador de ISS:

{
  "account_external_id": "1101000",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Caixa e equivalentes de caixa",
  "description": "Disponibilidades em caixa e em contas de liquidez imediata",
  "type": "A",
  "level": 3,
  "order_id": 3,
  "nature": 1,
  "sub_nature": "D",
  "parent_account": "11000",
  "split_code": "000",
  "status": "ACTIVE",
  "valid_from": "2026-10-01T00:00:00Z",
  "account_mappings": [
    { "group": "CodTrib IBS/CBS - DeRe", "account": "118915099" },
    { "group": "COSIF", "account": "1.1.1.10.00.00-8" }
  ],
  "code_mappings": [
    { "type": "dere_ind_trib_iss", "value": "0" }
  ]
}

Enviá el JSON con POST /accounts. Esperá 200 y consultá 1101000 para verificar los datos guardados; revisá las reglas DeRE antes de pedir la generación del evento.

4. Desdoblar una cuenta mixta

Después de crear 71000 y sus antecesoras, creá la cuenta original como sintética, sin codTrib ni ISS:

{
  "account_external_id": "7101000",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Rendas de empréstimos",
  "description": "Rendas de empréstimos",
  "type": "S",
  "level": 3,
  "order_id": 20,
  "nature": 4,
  "sub_nature": "C",
  "parent_account": "71000",
  "split_code": "000",
  "valid_from": "2026-10-01T00:00:00Z",
  "account_mappings": [
    { "group": "COSIF", "account": "7.1.1.05.00.00-8" }
  ]
}

Esperá 200 antes de enviar cada hija analítica con la misma cuenta COSIF y un codTrib distinto:

{
  "account_external_id": "7101001",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Rendas de empréstimos: operações de crédito",
  "description": "Rendas de operações de crédito",
  "type": "A",
  "level": 4,
  "order_id": 21,
  "nature": 4,
  "sub_nature": "C",
  "parent_account": "7101000",
  "split_code": "001",
  "valid_from": "2026-10-01T00:00:00Z",
  "account_mappings": [
    { "group": "CodTrib IBS/CBS - DeRe", "account": "311011101" },
    { "group": "COSIF", "account": "7.1.1.05.00.00-8" }
  ],
  "code_mappings": [
    { "type": "dere_ind_trib_iss", "value": "0" }
  ]
}

{
  "account_external_id": "7101002",
  "company_account_external_id": "CLI-98765",
  "location": "BR",
  "name": "Rendas de empréstimos: operações de câmbio",
  "description": "Rendas de operações de câmbio",
  "type": "A",
  "level": 4,
  "order_id": 22,
  "nature": 4,
  "sub_nature": "C",
  "parent_account": "7101000",
  "split_code": "002",
  "valid_from": "2026-10-01T00:00:00Z",
  "account_mappings": [
    { "group": "CodTrib IBS/CBS - DeRe", "account": "311011102" },
    { "group": "COSIF", "account": "7.1.1.05.00.00-8" }
  ],
  "code_mappings": [
    { "type": "dere_ind_trib_iss", "value": "0" }
  ]
}

Enviá cada body por separado con POST /accounts; esperá 200 y verificá las cuentas por GET. Si alguna solicitud falla, consultá la cuenta antes de repetir un envío que pudo haberse guardado.

Resolver errores

Errores de formato de la API

La API responde 400 y details presenta el primer error de formato detectado:

{
  "status_code": 400,
  "error": "Bad Request",
  "message": "Validation error: The provided data does not match the required format",
  "details": {
    "code": "INVALID_PARAMETERS",
    "message": "'split_code' must be 3 digits, from 000 to 999",
    "invalid_params": ["split_code"]
  }
}

Errores de reglas de negocio de la API

Estos errores usan response_data_body para describir la regla:

{ "response_data_body": "Parent account must be of type SYNTHETIC (S)", "status_code": 400 }

Reglas DeRE que la API no valida

La API puede guardar la cuenta aunque falle una de estas comprobaciones. Validalas antes de pedir el D-1011; Brinta no transmite un evento con errores.

• Código y jerarquía: código completo único, formado por código interno más split_code; nivel 1 sin padre; los demás niveles con padre sintético.
• Analíticas: description, exactamente un codTrib de nueve dígitos sin cero inicial y presente en la Tabla 11; indicador de ISS 0 o 1.
• Sintéticas: sin codTrib ni indicador de ISS.
• COSIF: una cuenta COSIF válida en todas las cuentas; las hijas desdobladas usan la misma que la original sintética.
• Desdoblamiento: si split_code es mayor que 000, la cuenta es analítica y su original (000) es sintética.
• Naturaleza y vigencia: nature de 1 a 5, sub_nature y valid_from informados en todas las cuentas.

Checklist antes de producción

• Empresa declarante dada de alta con su CNPJ; declaración DeRE configurada con Brinta.
• Token de API generado y empresa identificada con un único ID.
• Relación cuenta → codTrib y cuenta → COSIF definida por el equipo tributario.
• Convención de códigos (account_external_id y parent_account) validada con Brinta.
• Cuentas mixtas desdobladas; split_code informado en todas las cuentas.
• type, nature, sub_nature y valid_from completos; mappings requeridos presentes.
• Reglas DeRE anteriores validadas antes de enviar.
• Carga ordenada por nivel: padres antes de hijas.
• Manejo de 4xx y 5xx implementado; consulta previa a cualquier reintento de 500.
• Brinta avisada al terminar la carga para generar el D-1011.