El agente de Rivian para periodificar pedidos en SAP: procedimientos contables como instrucciones, asientos aparcados y aprobación humana

En dos frases

Rivian, el fabricante estadounidense de vehículos eléctricos, ha montado en Amazon Bedrock AgentCore un agente que prepara las periodificaciones de cierre de los pedidos de utillaje a medida en SAP S/4HANA: lee el procedimiento contable en texto, pide por correo las fechas de entrega a los responsables de cada pedido, calcula el importe y deja un asiento aparcado que un responsable de finanzas debe aprobar. Rivian y AWS dicen que elimina más de 15 días de trabajo manual por cierre, pero el relato sale del propio blog de AWS, no nombra el modelo y no publica volúmenes, así que conviene leerlo como un patrón bien documentado con resultados autodeclarados.

Quién lo hace y por qué interesa

Rivian diseña y fabrica la pickup R1T, los SUV R1S y R2 y una furgoneta eléctrica de reparto, con producción en Normal (Illinois) y unos 15.000 empleados según el artículo. Sus finanzas funcionan sobre SAP S/4HANA alojado en SAP HANA Enterprise Cloud. El caso se publicó el 13 de agosto de 2026 en el blog AWS for SAP, firmado por tres arquitectos de AWS y coescrito por dos empleados de Rivian: Arunkumar Malli, cuyo perfil público de LinkedIn le presenta como responsable sénior de ingeniería de la plataforma ERP en Rivian, y Sandeep Kodre. SAP también ha publicado un vídeo sobre el caso y PYMNTS lo recogió el 11 de septiembre de 2026.

El interés comercial es evidente: AWS vende Bedrock AgentCore y el texto se parece por momentos a un caso de referencia comercial. Lo recogemos igualmente por tres motivos:

• Es un problema contable concreto, no «IA para finanzas». Una matriz de estampación o un molde de inyección tarda de 12 a 24 meses en desarrollarse y la factura suele llegar 18 meses o más después del pedido. Según explica el artículo, los principios contables (US GAAP en su caso) obligan a reconocer el coste de forma gradual durante el desarrollo, así que alguien tiene que seguir cientos de pedidos abiertos, confirmar sus plazos y registrar cada mes la parte proporcional.
• Las decisiones de diseño están explicadas. Procedimientos guardados en una base de conocimiento en lugar de reglas programadas, rutas según importancia relativa, un servidor MCP entre el agente y SAP, asientos aparcados y aprobación humana.
• Es SAP y no gira alrededor de Claude. Después de varios casos con asistentes conversacionales, este es un desarrollo corporativo sobre un ERP que también usan muchos grupos españoles y europeos, con un marco de agentes independiente del modelo.

Herramientas y arquitectura

El blog enumera los componentes; cómo se conectan, tal y como lo dibujamos abajo, es nuestra lectura del texto y no un diagrama publicado por Rivian.

1. SAP S/4HANA contiene los pedidos de compra. El agente detecta excepciones «mediante eventos OData de SAP» y unas funciones de AWS Lambda sondean SAP de forma programada.
2. Un agente Strands en Amazon Bedrock AgentCore, «impulsado por un modelo LLM líder» que el artículo no identifica. Strands es el SDK de agentes de código abierto de AWS; AgentCore es la capa gestionada de ejecución, identidad y herramientas.
3. Amazon Bedrock Knowledge Bases guarda dos tipos de documentos: los procedimientos de periodificación y la documentación de las APIs de SAP. El agente recupera el procedimiento que corresponde a las características de cada pedido.
4. Un servidor MCP con herramientas propias: conectores a la API REST de SAP, correo con Amazon SES y gestión de casos. El artículo insiste en que cualquiera de ellas (proveedor de correo, base de datos, conector de SAP) se puede cambiar sin tocar la lógica del agente.
5. Amazon DynamoDB guarda el estado de cada caso y una pista de auditoría con fecha y hora que los autores vinculan a los requisitos de SOX.
6. Seguridad: AgentCore Identity para los servidores MCP, IAM y Cognito para el acceso por roles, Secrets Manager para las credenciales, CloudWatch para la supervisión y AWS CDK para la infraestructura como código.

Lo que hace el agente en cada ejecución, en el orden que da el blog: detectar excepciones, reunir contexto de DynamoDB y de la base de conocimiento, decidir la ruta, llamar a herramientas por MCP para leer SAP y enviar correos, calcular la periodificación proporcional al tiempo con un método lineal, crear asientos aparcados para revisión y gestionar el flujo de aprobación.

Hay dos detalles que se pasan por alto con facilidad. El primero: el artículo dice que el agente «adapta su enfoque» a cada pedido en lugar de seguir un camino fijo. Esa es la razón de usar un LLM y, a la vez, lo que más hay que controlar. El segundo: los asientos se aparcan, no se contabilizan. En SAP, un documento aparcado (o preliminar) queda guardado y visible, pero no afecta al libro mayor hasta que alguien lo completa, y ese es justo el punto donde colocar la aprobación humana.

Paso a paso para replicar el patrón

El artículo de Rivian da principios, no un manual de operación. Los pasos siguientes combinan esos principios con lo que cualquier equipo financiero con SAP necesitaría; cuando añadimos algo propio, lo decimos.

1. Elige una familia de periodificaciones con reglas escritas. Rivian empezó por los pedidos de utillaje a medida. Los buenos candidatos tienen muchas partidas abiertas, plazos largos, una fórmula explicable y una fuente fiable de fechas.
2. Escribe el procedimiento como manual de instrucciones del agente. Un documento breve por procedimiento: alcance, campos de datos, tramos de importancia relativa, qué fechas usar, fórmula, imputación contable, a quién escribir y cuándo parar. Lo mantiene finanzas: cambiar una regla es editar el documento, no pedir un desarrollo.
3. Carga los procedimientos y tus notas sobre las APIs de SAP en una base de conocimiento, para que el agente recupere el procedimiento adecuado para cada pedido en lugar de cargar todas las reglas en un único prompt enorme.
4. Expón SAP mediante herramientas acotadas. Lectura de pedidos abiertos, entradas de mercancía y facturas; escritura de una sola cosa: un asiento aparcado. Comprueba con tu equipo SAP qué interfaz lo permite en tu edición. Una respuesta aceptada en SAP Community indica que la API estándar de asientos de S/4HANA Cloud Public Edition contabiliza directamente y no permite aparcar; los conectores MCP de Rivian trabajan contra un S/4HANA alojado de forma privada, y el blog no dice qué API usan.
5. Clasifica por importancia relativa. Los pedidos pequeños y limpios se pueden calcular con las fechas del propio pedido; los grandes o antiguos deberían disparar un correo de confirmación al responsable y una revisión más atenta. Los tramos los fijas tú: Rivian no los publica.
6. Automatiza el seguimiento con el responsable del pedido. El agente le escribe, interpreta la respuesta y la registra. Guarda el correo original y las fechas extraídas en la pista de auditoría.
7. Registra cada paso con fecha y hora: versión del procedimiento usada, datos leídos, lo que dijo el responsable, el cálculo y quién aprobó.
8. Ejecuta en paralelo al menos un cierre. Compara línea a línea los asientos aparcados por el agente con tu hoja de cálculo antes de cambiar.
9. Mantén la aprobación humana y realimenta las correcciones. En Rivian, los responsables de finanzas aprueban cada asiento antes de contabilizarlo; cuando corrigen al agente, la corrección pasa al procedimiento.

Un extracto de procedimiento que el agente puede recuperar (nuestro, no de Rivian)

Rivian no ha publicado sus procedimientos ni sus prompts. Este esqueleto solo convierte los principios del blog en un formato adaptable; importes, tramos y cuentas son marcadores. En España, con el PGC, la contrapartida habitual de un gasto devengado sin factura es la cuenta 4009 (Proveedores, facturas pendientes de recibir o de formalizar), pero la imputación concreta, y si el utillaje es gasto o inmovilizado en curso, la decide tu política contable.

PROCEDIMIENTO: Periodificación de pedidos de utillaje a medida — versión [N], responsable [NOMBRE]

Alcance
- Pedidos abiertos con grupo de artículos [GRUPOS DE UTILLAJE], sin factura
  final y con fecha de inicio de desarrollo informada.

Datos que se leen (solo lectura)
- Cabecera y posiciones del pedido: importe, moneda, proveedor, responsable,
  fecha de inicio, fecha prevista de finalización.
- Facturas y entradas de mercancía registradas contra el pedido hasta hoy.
- Periodificación aprobada del mes anterior para ese pedido (del registro).

Tramos de importancia relativa (fíjalos tú)
- Menos de [IMPORTE A]: usar las fechas del pedido tal cual; sin correo.
- De [IMPORTE A] a [IMPORTE B]: escribir al responsable si la fecha de fin ya
  ha pasado o si la última confirmación tiene más de [N] días.
- Más de [IMPORTE B]: confirmar siempre con el responsable; marcar para
  revisión sénior.

Cálculo
- Meses transcurridos = meses completos desde el inicio hasta el cierre del
  periodo (como máximo, el total).
- Periodificación acumulada = importe del pedido × meses transcurridos / meses
  totales de desarrollo, menos lo ya facturado.
- Asiento del periodo = periodificación acumulada − acumulado ya registrado.
  Puede salir negativo (reversión) si las fechas se han movido.

Resultado
- Un asiento aparcado por pedido en la sociedad [SOCIEDAD], clase de documento
  [CLASE], cuentas [CUENTA DEBE] / [CUENTA HABER], referencia = número de
  pedido, texto = "Periodificación [PERIODO] proc. v[N]".

Para y pregunta a una persona cuando
- El responsable no conteste antes de [FECHA] o su respuesta contradiga el pedido.
- Lo facturado supere el importe del pedido o la moneda no coincida.
- Falte cualquier dato necesario para el cálculo.

Nunca
- Nunca contabilices ni completes un asiento aparcado. Nunca modifiques el pedido.

Un ejemplo concreto (cifras hipotéticas)

La fuente no da ni un pedido, ni un importe, ni un asiento, así que las cifras siguientes son inventadas para mostrar cómo se comporta el patrón.

Se encarga una matriz de estampación por 1.200.000 $, con desarrollo previsto de enero de 2026 a junio de 2027: 18 meses y todavía sin factura. En el cierre de septiembre de 2026 han pasado nueve meses. Según el procedimiento, la periodificación acumulada es 9/18 × 1.200.000 = 600.000,00; hasta agosto se registraron 533.333,33, así que el agente aparca un asiento de 66.666,67.

Supongamos ahora que el pedido supera el tramo de confirmación y que el responsable contesta que la matriz no estará lista hasta septiembre de 2027, con lo que el desarrollo pasa a 21 meses. La periodificación acumulada queda en 9/21 × 1.200.000 = 514.285,71, por debajo de lo ya registrado, y el asiento de septiembre es una reversión de 19.047,62. Por eso tiene sentido preguntar: una hoja de cálculo con las fechas antiguas del pedido habría periodificado de más, y el correo del responsable es la evidencia que el auditor querrá ver junto al asiento.

Resultados declarados

Todo lo de este apartado lo declaran Rivian o AWS; nada está medido de forma independiente.

• «Más de 15 días de trabajo manual por ciclo» eliminados (introducción del blog). Yogesh Yadav, director sénior de Sistemas Financieros Globales, añade que han «eliminado semanas de trabajo manual cada mes».
• Cinco semanas para la prueba de concepto, tras la cual la solución pasó a producción por la vía rápida.
• Auditoría: «los auditores externos han elogiado la transparencia» del proceso con el agente frente a los cálculos anteriores en hojas de cálculo.
• Escala: según el artículo, el sistema absorbe el «aumento significativo» de pedidos de utillaje tras el lanzamiento del R2.
• Lo que falta: número de pedidos, su valor («un gran volumen», «un valor anual significativo»), precisión o tasa de error, el modelo usado, el coste de funcionamiento y cualquier cambio medido en la duración del cierre.

PYMNTS tituló que el agente recorta «15 días a cada cierre». Leída con atención, la fuente habla de trabajo manual eliminado, que no es lo mismo que cerrar los libros 15 días naturales antes.

Limitaciones y riesgos

• Una sola fuente, y con interés. Todos los detalles vienen de un blog del proveedor; PYMNTS, Let’s Data Science y la página del vídeo de SAP lo repiten. No hemos encontrado una explicación técnica independiente de Rivian.
• Sin modelo, sin prompts, sin procedimientos. No puedes reproducir el comportamiento exacto de Rivian; sí su diseño.
• El criterio sigue siendo criterio. Si el coste del utillaje es gasto o inmovilizado, y en qué periodo se reconoce, es una decisión de política contable que el procedimiento tiene que dejar fijada. El artículo de Rivian habla de periodificar «gastos» según US GAAP; con el PGC o con NIIF la política y las cuentas pueden ser otras.
• Un agente que «se adapta» necesita límites. La flexibilidad que justifica un LLM es también lo que el auditor va a cuestionar. Herramientas acotadas, una única vía de escritura que solo aparca y un registro completo es lo que lo hace defendible.
• El correo como fuente de datos. Las respuestas pueden ser vagas, tardías o erróneas. El procedimiento necesita una regla por defecto cuando nadie contesta, y alguien debe hacerse cargo de los casos sin resolver.
• La edición de SAP importa. Poder crear asientos aparcados por API depende de tu edición y de tus interfaces: compruébalo antes de diseñar todo alrededor de eso.

Errores comunes

• Poner las reglas en el prompt en vez de en un procedimiento versionado. Finanzas pierde la capacidad de cambiarlas y el auditor no ve qué versión se aplicó.
• Dar al agente un usuario que contabiliza. Si puede contabilizar, tarde o temprano lo hará. Los asientos aparcados y un aprobador distinto son el control.
• Saltarse la importancia relativa. Escribir cada mes a todos los responsables acostumbra a la gente a ignorar los correos; no escribirles nunca deja fechas obsoletas en la periodificación.
• Olvidar que el asiento puede ser negativo. Cuando las fechas cambian, la respuesta correcta suele ser una reversión, no otra periodificación.
• Medir horas en vez de calidad. Sigue los asientos rechazados, la tasa de respuesta de los responsables y los ajustes posteriores al cierre, no solo el tiempo ahorrado.

Conclusiones

El caso de Rivian vale menos por su cifra estrella, que nadie fuera de Rivian y AWS puede comprobar, que por su forma: procedimientos contables escritos como documentos que el agente recupera, una capa de herramientas fina e intercambiable hacia SAP, una vía de escritura que solo puede crear asientos aparcados y un responsable de finanzas que aprueba cada uno. Ese patrón no depende de AWS ni de un modelo concreto, y encaja en cualquier familia de periodificaciones con reglas claras y fechas difíciles. Si lo pruebas, empieza por una sola familia, ejecútala junto a la hoja de cálculo durante un cierre y deja que el auditor vea, al lado de cada asiento, la versión del procedimiento y el correo del responsable.