Calculadora de período medio de cobro

Unas ventas a crédito nulas o negativas dejan el cociente indefinido, de modo que la tarea falla con invalid_input y no se factura.

Cómo se calculan los días de ventas pendientes y el período medio de cobro

De forma equivalente, forme primero las ventas a crédito diarias medias como credit_sales dividido entre days, y después divida accounts_receivable entre ese ritmo diario; ambas rutas son algebraicamente idénticas y esta capacidad usa la primera. Cuando usted omite days, el endpoint toma por defecto 365, la convención anual de los manuales. Un año bancario de 360 días o un trimestre de 90 es solo otro valor de days: la fórmula no cambia. El giro de cuentas por cobrar, informado cuando accounts_receivable es positivo, es ventas a crédito entre cuentas por cobrar, y el DSO es entonces days dividido entre ese giro.

Contrato de entrada, forma de la respuesta y errores

Si se aporta days y no es mayor que cero, la petición falla. Esos fallos no se facturan. Ejemplo: cuarenta y cinco mil de cuentas por cobrar frente a trescientos sesenta y cinco mil de ventas a crédito anuales producen un período de cobro de cuarenta y cinco días y mil de ventas a crédito diarias medias. Envíe por POST un cuerpo JSON con dos números finitos obligatorios y una duración de período opcional. accounts_receivable es el saldo pendiente de cobro de la ventana (AR de cierre, o AR medio si esa es la convención que ya usa internamente); los alias ar y receivables apuntan al mismo campo. credit_sales son las ventas a crédito totales —netas de devoluciones si así cierra el libro— de la misma ventana; se aceptan los alias sales, total_credit_sales y net_credit_sales para que los libros conserven el nombre de sus columnas. days es el número de días de esa ventana y vale 365 cuando se omite; se aceptan los alias period_days y days_in_period. Cada campo numérico puede llegar como número JSON o como cadena numérica. Los campos ausentes, las cadenas vacías y los valores no finitos fallan con invalid_input nombrando el campo. Si accounts_receivable es negativo, la petición falla. Si la validación pasa, el cuerpo repite accounts_receivable, credit_sales y days, e informa average_daily_credit_sales, days_sales_outstanding y average_collection_period (las dos últimas son la misma cifra redondeada, devuelta con ambos nombres para que un panel DSO y una hoja ACP compartan un contrato). Cuando las cuentas por cobrar son positivas, el cuerpo incluye también receivables_turnover. Combine el JSON con sus propios tramos de antigüedad si necesita el relato por cliente; este endpoint devuelve la media del período, no un calendario de facturas.

Dónde aporta valor una calculadora del período medio de cobro

Los equipos de producto integran el contrato en paquetes de cierre ERP, informes de consejo y pruebas CI que deben fijar days_sales_outstanding sin llamar a una API del libro mayor. Como la implementación es parse pura de nivel A, cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente. Mantenga credit_sales estrictamente positivo, accounts_receivable no negativo, fije en las pruebas la cifra de días redondeada y obtendrá períodos de cobro reproducibles para listas de cierre, plugins LMS y workers de borde sin montar un motor de cuentas por cobrar propio.