Por qué el calendario de pagos Shimebi japonés
es más difícil de lo que la mayoría de los equipos de AP creen

El sistema Shimebi: un calendario de pagos diseñado por treinta personas distintas

El sistema de ciclos de facturación de Japón —la convención shimebi (締日)— no es un sistema único. Son treinta sistemas, cada uno definido por un contrato entre un comprador y un proveedor, y el contrato especifica dos cosas: el día del mes en que se cierra el período de facturación (el día de cierre, 締日) y cuántos meses después debe llegar el pago (el desfase de pago, expresado en una sintaxis compacta como 翌月末払い o 翌々月10日払い). Una empresa que compra a treinta proveedores tiene hasta treinta combinaciones distintas de día de cierre y desfase de pago, porque cada proveedor negoció sus propias condiciones al inicio de la relación, y esas condiciones están integradas en el contrato de compra, no estandarizadas por ningún organismo del sector ni plataforma.

Las combinaciones más comunes forman un conjunto pequeño, pero ese conjunto sigue siendo más grande que un solo calendario:

La tabla revela el problema estructural: la misma fecha de factura —10 de marzo— produce cuatro fechas de vencimiento de pago distintas según el proveedor que la emitió. Los proveedores A y B cierran el día 15 y 20 respectivamente, ambos exigen el pago a finales de abril. El proveedor C cierra a fin de mes, pero exige el pago para el 10 de mayo. El proveedor F cierra el día 10 y quiere el pago para el 25 de abril. El administrativo de cuentas por pagar no puede mirar la fecha del calendario «10 de marzo» y saber cuándo pagar. La cadena de condiciones de pago —incrustada en el PDF de la factura como texto, no como un campo de datos estructurado— debe leerse, analizarse y convertirse en una fecha del calendario para cada factura, cada mes. Con treinta proveedores, el equipo de cuentas por pagar está gestionando treinta calendarios de pago diferentes simultáneamente, y el calendario de ningún proveedor tiene relación alguna con el de ningún otro.

Esto no es una peculiaridad japonesa. Es una consecuencia directa de un sistema de facturación donde cada contrato bilateral define sus propias condiciones. La mayoría de los países usan Net 30, Net 60 o Net 90 — fecha de factura más un número fijo de días. Japón usa un sistema de dos partes: día de cierre más demora de pago, donde la demora se expresa en meses, no en días, y el número real de días varía según la duración del mes. Abril tiene 30 días; mayo, 31; febrero, 28 o 29. La fecha de vencimiento bajo 末日締翌月末払い para una factura del 10 de marzo es el 30 de abril — una demora de 20 días desde el día de cierre (31 de marzo al 30 de abril). Para una factura del 25 de marzo bajo las mismas condiciones, la demora también es hasta el 30 de abril — una demora de 30 días desde el día de cierre, porque el propio día de cierre varía según la duración del mes. Un sistema Net 30 daría a ambas facturas la misma fecha de pago relativa a la fecha de factura. El sistema shimebi les da la misma fecha de pago relativa al día de cierre. El empleado de cuentas por pagar debe hacer seguimiento de ambas.

La documentación de localización de NetSuite para Japón lo explica claramente: «las empresas acuerdan una fecha de cierre con los clientes antes de iniciar transacciones comerciales. La fecha de vencimiento del pago es fija, lo que significa que el número de días entre la fecha de cierre y la fecha de vencimiento varía según los días que tenga cada mes». Los principales sistemas ERP manejan la lógica shimebi de forma nativa, siempre que alguien haya ingresado la fecha de cierre y la fecha de vencimiento de cada proveedor en el maestro de proveedores. La brecha está en el paso anterior al ERP: obtener las condiciones de pago de la factura en PDF e ingresarlas en el sistema.

Treinta proveedores, treinta calendarios, un plazo que nadie gestiona

El equipo de cuentas por pagar que gestiona treinta relaciones con proveedores no enfrenta un plazo de pago al mes. Enfrenta treinta plazos de pago, distribuidos en dos o tres fechas de calendario al mes, cada uno activado por un día de cierre diferente que cierra en un día distinto del mes. La consecuencia práctica no es dificultad aritmética — un empleado competente de cuentas por pagar puede interpretar «末日締翌々月10日払い» en segundos. La consecuencia práctica es que el calendario es invisible hasta que alguien revisa cada factura individualmente.

Un equipo de cuentas por pagar en EE. UU. puede escanear una lista de fechas de factura y sumar mentalmente treinta días. Un equipo en Japón no puede escanear una lista de fechas de factura en absoluto — la fecha de factura es información insuficiente. La única forma de saber la fecha de vencimiento es leer el campo de condiciones de pago en cada factura. Si llegan treinta facturas, el equipo lee treinta campos de condiciones de pago y calcula treinta fechas de vencimiento. Si las condiciones de pago de una factura se leen mal — si «20日締翌月末払い» se confunde con «末日締翌月末払い» porque el día de cierre difiere en diez días — la fecha de vencimiento puede ser la misma (ambas a fin del mes siguiente), pero la clasificación del período fiscal puede ser incorrecta. El gasto pertenece a un mes diferente en el libro mayor, lo que se traslada a los estados financieros trimestrales y a la declaración del impuesto al consumo.

La fragmentación del calendario se agrava entre departamentos. El equipo de tesorería necesita conocer la salida total de efectivo por fecha para gestionar el capital de trabajo. El equipo de compras necesita saber si las condiciones de pago de un proveedor han cambiado desde la última renovación del contrato. El equipo de impuestos necesita saber qué facturas caen en cada período de declaración del impuesto al consumo. Cada equipo solicita al equipo de cuentas por pagar un corte diferente de los mismos datos — por fecha, por proveedor, por período fiscal — y el equipo de cuentas por pagar, mirando treinta facturas individuales cada una con condiciones de pago integradas que deben interpretarse una por una, no puede producir ninguna de estas vistas sin antes ingresar las treinta facturas en una hoja de cálculo y luego manipular esa hoja. El paso de ingreso de datos es el cuello de botella. El problema del calendario está aguas abajo del problema de extracción de datos.

Lo que realmente cuesta incumplir un plazo — Más allá de la multa por pago atrasado

El costo visible de no cumplir con el plazo de pago a un proveedor son los intereses legales de demora (遅延損害金, chien songaikin). Según el artículo 514 del Código Comercial de Japón (商法), la tasa de interés legal para transacciones comerciales entre empresas es del 6% anual. Una factura de ¥500.000 pagada con treinta días de retraso genera aproximadamente ¥2.466 en intereses de demora — una cantidad lo suficientemente pequeña como para que la mayoría de los equipos de cuentas por pagar prefieran negociar una exención antes que calcular los intereses, pero lo suficientemente grande como para que, en treinta proveedores a lo largo de doce meses, la exposición agregada se convierta en una partida en la auditoría anual.

Pero la multa legal es el costo que el departamento de contabilidad puede ver. Los costos que no puede ver son mayores y más difíciles de medir:

Deterioro de la relación con el proveedor. Un proveedor que recibe el pago el día 31 cuando el contrato estipulaba el día 10 no recurre de inmediato a acciones legales. Envía un recordatorio cortés. El segundo pago atrasado provoca una llamada telefónica al gerente de compras. El tercer pago atrasado cambia el comportamiento del proveedor: puede comenzar a solicitar el pago por adelantado, acortar los plazos de crédito de forma unilateral, despriorizar los pedidos del comprador durante las temporadas altas o ajustar los precios unitarios al alza en la próxima negociación del contrato para compensar el costo del capital de trabajo por mantener la cuenta por cobrar del comprador. Estos ajustes no se detallan como "respuesta al pago atrasado". Están integrados en el precio unitario de la siguiente orden de compra, invisibles para el equipo de cuentas por pagar que los desencadenó.

Error en la previsión del flujo de caja. Cuando el calendario de pagos es incorrecto — cuando seis facturas con vencimiento el 10 de mayo se ingresaron erróneamente como vencidas el 31 de mayo — la previsión de flujo de caja del equipo de tesorería sobreestima el efectivo disponible por el total de esas seis facturas durante el lapso de veintiún días. La empresa puede tomar decisiones de gasto basándose en una posición de efectivo inexacta. El error no se descubre hasta el 11 de mayo, cuando seis proveedores preguntan sobre el estado del pago — momento en el cual el efectivo ya se ha asignado a otro lugar, y el equipo de tesorería debe apresurarse para cubrir el déficit. El costo de esa urgencia — intereses de sobregiro, pagos retrasados a otros proveedores o el costo interno de tiempo por reelaborar la previsión de efectivo — no se contabiliza como un costo de pago atrasado.

Doble exposición al impuesto de retención en origen. Una factura de proveedor que lleva una clasificación de 源泉徴収 (gensen chōshū) debe tener retenido el 10,21% antes del pago. Si el equipo de cuentas por pagar no cumple con el plazo de pago y además omite la retención — un error compuesto común al procesar con rapidez — la empresa paga el importe total al proveedor (un sobrepago del 10,21%) y aún debe el importe retenido a la oficina de impuestos como un depósito separado. El pago atrasado del impuesto de retención en origen a la oficina de impuestos genera sus propios intereses de demora, independientes del pago comercial atrasado al proveedor. Un solo plazo de pago incumplido en una factura sujeta a retención puede generar dos flujos de multas separados.

El riesgo de cumplimiento de la 下請法 (Ley de Subcontratación). Para las empresas que actúan como contratistas principales según la Ley de Transacciones Adecuadas con Pequeños y Medianos Operadores Comerciales Subcontratados de Japón, el plazo legal de pago es de 60 días desde la entrega de bienes o servicios. El pago tardío bajo la Ley de Subcontratación conlleva una penalización anual del 14,6 %, más del doble de la tasa del Código Comercial, aplicada por la Comisión de Comercio Justo de Japón. Una enmienda de 2025 (vigente desde enero de 2026) fortaleció la Ley al prohibir el pago mediante pagarés y ampliar su cobertura. Para una empresa que califica como contratista principal de pequeños y medianos subcontratistas, incumplir el plazo de 60 días no es un problema de relación con proveedores. Es una infracción normativa que la Comisión de Comercio Justo puede investigar.

Por qué la hoja de cálculo no puede resolver el problema de raíz

La hoja de cálculo es la herramienta que los equipos de AP usan para gestionar el calendario. También es la herramienta que demuestra más claramente por qué el problema del calendario no se resuelve con mejor disciplina de calendario. La hoja de cálculo tiene una columna para la fecha de vencimiento del pago. Esa columna debe ser llenada por una persona que lea las condiciones de pago de cada factura en PDF y convierta «末日締翌々月10日払い» en una fecha del calendario. La hoja de cálculo puede almacenar el resultado de esa conversión. No puede realizar la conversión por sí misma, porque la hoja de cálculo no puede leer la factura.

Esto significa que la precisión de la hoja de cálculo depende completamente del paso de lectura humana. Cada factura, cada mes, el empleado de AP lee el campo de condiciones de pago, lo interpreta mentalmente y escribe una fecha en la hoja de cálculo. El paso es rápido: un empleado competente puede analizar una cadena de shimebi en segundos. La fragilidad del paso no está en su velocidad sino en su integridad: treinta facturas, treinta eventos de interpretación, treinta oportunidades de leer mal un día de cierre, aplicar incorrectamente un desfase de pago, o pasar por alto un campo de condiciones de pago porque el empleado fue interrumpido por una llamada entre la factura veintitrés y la veinticuatro. En un sistema Net 30, una factura con fecha 10 de marzo siempre vence el 9 de abril: una fórmula puede generar la fecha sin intervención humana. En el sistema shimebi, una factura con fecha 10 de marzo y condiciones de pago «末日締翌々月10日払い» vence el 10 de mayo. La fecha «10 de marzo» por sí sola es inútil. La fórmula no puede ejecutarse sin las condiciones de pago como entrada, y las condiciones de pago solo existen en el PDF de la factura, un formato al que la hoja de cálculo no puede acceder.

La misma brecha estructural se aplica a cada proceso posterior que depende del calendario de pagos. La previsión de flujo de caja del equipo de tesorería solo es tan precisa como las fechas de vencimiento que ingresó el equipo de AP. La asignación del período del impuesto al consumo del equipo fiscal solo es tan precisa como los días de cierre que interpretó el equipo de AP. La auditoría de condiciones de pago a proveedores del equipo de compras solo es tan precisa como los términos contractuales más recientes que consultó el equipo de AP. Todo el calendario de pagos se asienta sobre una base de lectura humana de PDFs, una base que ninguna función de hoja de cálculo puede reforzar, porque la hoja de cálculo comienza en el punto donde la lectura ya ha ocurrido. Si el paso de lectura produce un error, la hoja de cálculo lo almacena y propaga fielmente.

El problema que la mayoría llama "seguimiento de plazos de pago" son en realidad dos problemas fusionados. El primero es extraer las condiciones de pago de la factura — leer "末日締翌々月10日払い" del PDF y convertirlo en datos estructurados. El segundo es hacer el seguimiento de esas fechas de vencimiento estructuradas entre treinta proveedores. La hoja de cálculo puede resolver el segundo problema. No puede resolver el primero. El primer problema — el problema de extracción — es lo que hace que el problema del calendario sea irresoluble con las herramientas que la mayoría de los equipos de AP ya tienen. La guía paso a paso para extraer datos de facturas japonesas cubre la estructura completa de campos que captura un flujo de extracción, incluyendo las condiciones de pago y sus días de liquidación calculados — los datos estructurados que un calendario necesita como entrada. La misma brecha entre las condiciones de pago en la factura y la fecha de pago en el ERP impulsa el cuello de botella de conciliación OC-recepción-factura en el lado de compras: una conciliación requiere que los tres documentos coincidan en las condiciones, y las condiciones viven en cadenas de texto en los PDF.

Dónde está realmente la solución — y por qué no es un cambio de flujo de trabajo

El problema del calendario en AP japonés se diagnostica erróneamente como un problema de programación. La solución propuesta suele ser "una mejor gestión del calendario" — un calendario compartido del equipo, recordatorios automáticos, una reunión semanal de revisión de pagos. Ninguna de estas soluciones cambia el hecho de que la fecha de vencimiento del pago no está en la factura como una fecha. Está en la factura como una cadena de texto que debe analizarse. Una mejor gestión del calendario embellece el calendario. No cierra la brecha entre la cadena de texto en el PDF y la fecha en la celda del calendario.

La solución está en la capa de extracción — el paso donde los datos pasan del PDF de la factura a un formato estructurado. Si el paso de extracción produce no solo el texto bruto de las condiciones de pago, sino el día de liquidación analizado y el desfase de pago como valores estructurados separados, el calendario puede poblarse solo. Una columna como Día de liquidación (de Condiciones de pago: generar el número del día) y Meses de desfase de pago (de Condiciones de pago: generar el número de meses) — dos columnas calculadas que la IA deriva durante la extracción — convierten "末日締翌々月10日払い" en Día de liquidación: 31 y Meses de desfase de pago: 2 (con pago el día 10). Una fórmula de hoja de cálculo puede entonces calcular la fecha de vencimiento real a partir de la fecha de la factura más el día de liquidación más el desfase de pago. El paso de extracción alimenta al calendario con la entrada estructurada que necesita. El empleado de AP ya no lee ni analiza. El empleado de AP verifica.

Esto no es un cambio de flujo de trabajo. Es un cambio en el canal de datos — conectar el PDF de la factura directamente al calendario de pagos extrayendo las condiciones de pago como datos estructurados en lugar de como una cadena de texto opaca que un humano debe interpretar. El mismo canal que alimenta el calendario de pagos alimenta la previsión de flujo de caja, la asignación del período del impuesto al consumo y la auditoría de condiciones de pago de proveedores. El problema del calendario desaparece no porque el calendario mejoró, sino porque los datos que alimentan el calendario dejaron de depender de un humano.

El mismo principio — cerrar la brecha entre el documento y la decisión mediante la extracción de datos estructurados — impulsa el flujo de trabajo de procesamiento por lotes de facturas, donde treinta facturas producen una hoja de cálculo lista para pagar con detalles de transferencia bancaria, cálculos de retención y calendario de pagos agrupado por día de liquidación. Y refleja la visión estructural del análisis de presentación de BAS australiano: el formulario toma noventa segundos; el ensamblaje toma días. En ambos casos, el plazo visible oculta el paso invisible de ensamblaje de datos, y el paso de ensamblaje es exactamente donde la capa de extracción cierra la brecha.

Preguntas Frecuentes

¿Por qué el sistema ERP no puede gestionar automáticamente las condiciones de pago Shimebi?

Sistemas ERP como NetSuite, SAP y Oracle E-Business Suite sí gestionan las condiciones de pago basadas en Shimebi japonés, pero solo después de que dichas condiciones se hayan ingresado en el registro maestro de cada proveedor. El módulo de localización japonesa de NetSuite, por ejemplo, permite definir un patrón de día de cierre y una fecha de vencimiento de pago por proveedor, y el sistema calcula automáticamente la fecha de vencimiento para cada transacción. La brecha está en obtener las condiciones de pago del PDF de la factura del proveedor e ingresarlas en el maestro de proveedores. Cuando un nuevo proveedor envía su primera factura con condiciones de pago "20日締翌月末払い", alguien debe leer ese texto del PDF y configurar el patrón de día de cierre del ERP en consecuencia. El ERP maneja el cálculo continuo, pero no la extracción inicial.

¿Todas las empresas japonesas utilizan condiciones de pago Shimebi?

La mayoría lo hace para transacciones B2B nacionales. El sistema está profundamente arraigado en la práctica comercial japonesa. Algunos sectores —particularmente grandes minoristas que tratan con muchos proveedores pequeños— han comenzado a migrar hacia pagos con fecha fija (por ejemplo, "pago el día 25 del mes siguiente" independientemente de los ciclos de facturación individuales), pero la convención Shimebi sigue siendo el modelo dominante. Para una empresa mediana que recibe facturas de treinta proveedores, la expectativa realista es que veinticinco o más utilicen condiciones basadas en Shimebi, y las condiciones de cada proveedor pueden ser diferentes.

¿Cómo interactúa el límite de 60 días de la Ley de Subcontratación con las condiciones de pago Shimebi?

La Ley de Subcontratación exige que los contratistas principales paguen a los subcontratistas dentro de los 60 días posteriores a la recepción de los bienes o servicios. Un contratista principal que negocia condiciones de pago de "末日締翌々月末払い" (cierre a fin de mes, pago a fin del mes siguiente al siguiente) con un subcontratista que entrega el día 1 del mes podría enfrentar una ventana de pago de aproximadamente 60 a 90 días, dependiendo de cuándo caiga la entrega en relación con el ciclo de facturación. Esta combinación —un largo desfase Shimebi más el límite legal de 60 días— crea un riesgo de cumplimiento que requiere monitoreo activo. La penalización por pago atrasado del 14,6% según la Ley de Subcontratación lo convierte en el error de calendario más costoso que una empresa puede cometer.

¿Qué sucede cuando un proveedor cambia sus condiciones de pago a mitad del contrato?

Un proveedor puede cambiar sus condiciones de pago en la renovación del contrato o, en algunos casos, de forma unilateral actualizando las condiciones impresas en sus facturas. Si el equipo de cuentas por pagar procesa las facturas utilizando las condiciones antiguas del registro maestro del proveedor mientras este ya ha cambiado a las nuevas, el calendario de pagos será incorrecto para ese proveedor hasta que se descubra el desajuste. Esto es más común con proveedores que cambian de pago a fin de mes siguiente a pago a fin del segundo mes siguiente para mejorar su propia posición de caja; el equipo de cuentas por pagar paga según el calendario anterior (más corto), lo que es favorable para el proveedor, por lo que este no tiene incentivos para señalar la discrepancia. El desajuste persiste hasta que una auditoría o una anomalía en el flujo de caja llama la atención sobre él.

El problema del calendario para el que nadie crea un panel de control

La gestión del calendario de pagos en las cuentas por pagar japonesas es un problema que no genera su propio panel de control porque el síntoma —un plazo de pago incumplido— parece un error puntual, no un fallo sistémico. El proveedor envía un recordatorio. El equipo de cuentas por pagar se disculpa y procesa el pago. El incidente se cierra. La causa raíz —que la fecha de vencimiento del pago nunca estuvo en la factura como una fecha, sino solo como una cadena de texto que un humano tuvo que interpretar, y el humano la interpretó mal— no aparece en el informe del incidente. No aparece en ningún lado, porque los datos que la revelarían (las condiciones de pago en la factura frente a la fecha de vencimiento en la hoja de cálculo) residen en dos sistemas diferentes, y nadie los compara a menos que un error fuerce la comparación.

La brecha es estructural: la factura contiene las condiciones de pago en un formato que una computadora no puede utilizar (texto incrustado en un PDF). El equipo de cuentas por pagar lo convierte a un formato que una computadora sí puede utilizar (una fecha de calendario en una hoja de cálculo) mediante un paso que depende completamente de la atención humana: leer, interpretar, escribir. Con treinta proveedores, treinta facturas al mes, doce meses al año, este paso ocurre 360 veces. La tasa de error es baja en términos porcentuales y costosa en términos absolutos, porque cada error se propaga a las relaciones con los proveedores, las previsiones de flujo de caja, las declaraciones de impuestos y la exposición al cumplimiento normativo. La solución no es un mejor calendario. La solución es cerrar la brecha: hacer que el paso de extracción produzca datos estructurados de condiciones de pago que un calendario pueda consumir directamente, de modo que el calendario se derive de la factura y no de la lectura humana de la factura.