Calculadora de utilización de crédito

Un límite de crédito total igual a cero se rechaza con invalid_input y no se factura, porque dividir entre cero no define una tasa de utilización.

Qué significa la utilización de crédito y cómo los dos totales se vuelven un porcentaje

En símbolos, utilization_ratio es igual a total_balance dividido entre total_credit_limit, y utilization_percent es ese ratio por cien. Una tarjeta sin usar con saldo cero y un límite de cuatro mil sigue ampliando total_credit_limit y baja el porcentaje global; cerrar esa tarjeta más tarde puede subir la utilización de un día para otro aunque usted no haya pedido nada nuevo. Una comprobación resuelta es un saldo combinado de dos mil sobre un límite combinado de seis mil: el ratio es un tercio y utilization_percent ronda 33.33. Eso queda justo por encima de la pauta habitual del 30 por ciento que muchos asesores citan antes de una consulta hipotecaria. Cuando el saldo combinado supera el límite combinado, la cartera está por encima del límite, el porcentaje pasa de cien, available_credit es cero y over_limit_amount registra el exceso.

Contrato de entrada, forma de la respuesta y comportamiento ante errores

Esos fallos no se facturan. Envíe por POST un cuerpo JSON con dos números finitos obligatorios. total_balance es el saldo revolving pendiente combinado en una sola unidad monetaria; los alias balance, balances, total_balances y outstanding apuntan al mismo campo para que un extracto de estado de cuenta conserve el nombre de sus columnas. total_credit_limit es el límite de crédito revolving combinado en esa misma moneda; se aceptan los alias credit_limit, limit, total_limit y creditLimit. 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. total_balance debe ser mayor o igual que cero: un saldo nulo es un caso legítimo de crédito sin usar y devuelve utilization_percent de cero en vez de un error. Un saldo negativo se rechaza. total_credit_limit debe ser estrictamente mayor que cero. Un saldo mayor que el límite está permitido: la cartera está por encima del límite, utilization_percent supera cien, over_limit es true, available_credit es cero y over_limit_amount registra el excedente en vez de recortar el porcentaje. Si la validación pasa, el cuerpo repite los dos totales redondeados half-up a dos decimales, e informa utilization_ratio redondeado a seis cifras, utilization_percent redondeado a dos, available_credit, over_limit_amount, el booleano over_limit y una cadena de fórmula que reafirma la identidad. Ejemplo: dos mil de saldos combinados sobre un límite combinado de diez mil producen una utilización del veinte por ciento, ocho mil de crédito disponible y over_limit false. Combine el JSON con su propia lista de las cuentas que sumó: este endpoint divide las dos cifras que usted envía; no extrae un fichero de agencia, no envejece una puntuación ni reconstruye filas por tarjeta.

Dónde aporta valor una calculadora de utilización de crédito

Esta herramienta no extrae un informe de crédito, no envejece una puntuación al estilo FICO y no modela líneas de usuario autorizado, fallidos ni la diferencia entre los saldos de extracto reportados y el saldo en vivo de hoy. Combínela con su propio extracto de agencia cuando la pregunta sea qué ven ya las agencias, y use esta calculadora cuando la pregunta sea qué implican ahora dos totales revolving conocidos. Los asesores de crédito y los coaches de entidades sin ánimo de lucro usan el endpoint de dos números cuando el cliente ya tiene los totales del extracto en la mano y solo quiere el porcentaje, el margen restante y si la cartera está por encima del límite, sin teclear cada tarjeta. Los equipos de producto y de suscripción envían la API JSON por lotes sobre extractos que ya publican saldos revolving combinados y límites combinados, y fijan utilization_percent en las pruebas en vez de volver a derivarlo en cada servicio. Las unidades de preparación de exámenes y de aula necesitan un oráculo determinista que trate un límite cero como invalid_input y no como una división entre cero, permita porcentajes por encima del límite superiores a cien y devuelva tanto el ratio como el porcentaje. 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, y la validación fallida no consume saldo. Mantenga las peticiones pequeñas y fije utilization_percent más available_credit en las pruebas. Mantenga total_credit_limit estrictamente positivo, envíe ambas cifras en una sola moneda y obtendrá un porcentaje de utilización reproducible para páginas de aterrizaje, plugins LMS y workers de borde sin montar un motor por tarjeta propio.