Qué tal,

Tengo algunas dudas respecto al funcionamiento del redondeo en los CFDI, tanto en el XML como en su representación en PDF.

Actualmente estoy intentando generar el siguiente comprobante, en el cual los valores en los conceptos se expresan con hasta seis decimales, mientras que en la sección de impuestos y totales, estos valores se redondean a dos decimales (consultar XML aquí):
https://pastebin.com/TLzLTEvF

A nivel de concepto, los cálculos con seis decimales son los siguientes:

Code:

| Concepto | Monto | |-------------------|---------------| | Bruto | 11,076.915331 | | IVA (traslado) | 1,772.306453 | | ISR (retenido) | 1,107.691533 | | IVA retenido | 1,181.530251 | | *Total neto* | 10,560.000000 |

Como se puede observar, el cálculo exacto da como resultado un total neto cerrado de $10,560.00. Sin embargo, debido al redondeo a dos decimales aplicado aparentemente antes de la suma total, el comprobante final muestra un total de $10,560.01, generando una diferencia que no existía con los valores completos.

Mi pregunta es si este redondeo anticipado a dos decimales se debe a una limitante técnica del proveedor de facturación, o si es un comportamiento exigido directamente por el SAT.

En el documento oficial del SAT, disponible en:
http://omawww.sat.gob.mx/informacion_fiscal/factura_electronica/Documents/cfdi/PyRFactElect.pdf

Se menciona explícitamente en el inciso 7.2 que:
Por cada concepto de la factura se puede utilizar de cero hasta seis decimales como máximo, y en los totales se debe redondear al final del cálculo, al número de decimales que soporta la moneda.

El propio documento da este ejemplo:

Code:

| Conceptos | Base | Tasa o Cuota | Monto del impuesto | |------------|--------|--------------|--------------------| | Servicio 1 | 1.1100 | 0.1600 | 0.1776 | | Servicio 2 | 1.1100 | 0.1600 | 0.1776 | | Servicio 3 | 1.1100 | 0.1600 | 0.1776 | | Servicio 4 | 1.1100 | 0.1600 | 0.1776 | | *Totales* | 4.4400 | | 0.7104 |

El total del impuesto se calcula con cuatro decimales (0.7104), y luego se redondea al final a dos decimales (0.71). Esto permite que los CFDI sean válidos y timbrados correctamente, sin inconsistencias.

Agradecería mucho su orientación para entender si este tipo de discrepancias corresponden al proveedor de facturación o, en su caso, si se deben a políticas establecidas por el SAT. En ese escenario, agradecería una explicación más detallada.

De ser una limitante del SAT, cómo se resuelve un caso como el siguiente, utilizando el mismo esquema de rentenciones del XML:

Code:

| Importe Bruto | IVA (16%) | ISR (10%) | Ret. IVA (10.6667%) | Total Neto | |---------------|-----------|-----------|----------------------|------------| | 11.53 | 1.84 | 1.15 | 1.23 | 10.99 | | 11.54 | 1.85 | 1.15 | 1.23 | 11.01 |

En donde a 2 decimales, no es matemáticamente posible lograr un total neto con $11.00 entero (sin decimales).

Quedo atento a sus comentarios, y agradezco de antemano su apoyo.

Saludos cordiales.


Editado: Julio 25, 2025 19:57:47

Hola,

Tu caso es muy claro: el redondeo anticipado normalmente no es una exigencia del SAT, sino una limitación de cálculo de algunos PAC o sistemas de facturación. Según la regla oficial, se deben mantener los decimales completos en cada concepto y redondear solo al final en los totales.
Retro Bowl
Cuando pasa lo que describes (desajustes por redondeo previo), suele ser un tema de configuración del sistema de facturación, no del SAT. Lo ideal es ajustar tu sistema para que conserve los decimales internos hasta el cálculo final, o en su defecto documentar la diferencia en notas de CFDI si no hay forma técnica de evitarla.



Editado: Julio 26, 2025 00:44:02