Reconocimiento de ingresos en e-commerce: De acuerdo a las NIF, IFRS y regulación vigente en México

El resultado es un desfase que la mayoría de los sistemas de e-commerce no resuelve solo: el momento en que la norma contable reconoce el ingreso, el momento en que la ley fiscal lo acumula y el momento en que se causa el IVA rara vez coinciden. Y encima, la información debe entregarse al SAT con un nivel de detalle por operación que las pólizas agrupadas por Batch, y en muchos casos no se tiene este nivel detalle.

En este artículo vamos a revisar las cuatro capas del problema:

• El reconocimiento contable conforme a la NIF D-1 y la IFRS 15, el tratamiento de costos de la NIF D-2,
• La causación fiscal conforme a la LISR y la LIVA
• El cumplimiento de la contabilidad electrónica del Código Fiscal de la Federación y su Anexo 24.
• La arquitectura operativa que recomendamos para que el ERP no se convierta en el cuello de botella.

1. Por qué el e-commerce rompe el registro tradicional de ingresos

Antes de hablar de las regulaciones conviene establecer con precisión cuáles son sus particularidades. En una venta tradicional de mostrador, el cobro, la entrega y la facturación ocurren en el mismo acto. En comercio electrónico esos tres eventos se separan, y cada uno tiene un impacto diferente:

• Volumen atomizado. Miles de operaciones de bajo importe, muchas de ellas con público en general, que el sistema tiende a resumir en un solo registro diario.
• Cobro anticipado a la entrega. El flujo es la autorización del pago en el checkout, pero el producto se entrega días después regularmente. Contablemente el ingreso todavía no se debe reconocer; por otro lado, fiscalmente ya, se debe reconocer.
• Intermediación. Marketplaces, dropshipping y esquemas de fulfillment introducen a un tercero entre la empresa y el consumidor, lo que obliga a definir si se actúa como principal o no.
• Liquidación neta. El dinero que llega al banco no es la venta: es la venta menos comisiones, menos retenciones, menos contracargos y menos reembolsos, y muchas veces corresponde a un corte que no coincide con el mes contable.
• Devoluciones. En ciertas categorías la tasa de devolución es de dos dígitos, lo que convierte a la estimación de devoluciones en una partida relevante y no en un ajuste marginal.

2. El modelo de los cinco pasos (NIF D-1 / IFRS 15) aplicado al e-commerce

La NIF D-1, Ingresos por contratos con clientes, y su equivalente internacional IFRS 15, establecen un modelo único de cinco pasos. La norma es la misma para una constructora y para una tienda en línea; lo que cambia es cómo se aterriza. En la tabla siguiente detallamos el proceso del reconocimiento de ingreso y lo explicamos para el entorno digital.

3. ¿Principal o agente? La decisión que redefine tu estado de resultados

Cuando en la operación intervienen terceros como por ejemplo un marketplace, un proveedor en dropshipping, un operador logístico, surge la pregunta de fondo: ¿el ingreso es el importe total de la venta o únicamente la comisión? La respuesta no depende de quién cobra, sino de quién controla el bien antes de transferirlo al cliente.

La distinción es crucial. Registrar el bruto siendo agente inflaría artificialmente los ingresos, distorsiona los márgenes, altera razones financieras que los bancos revisan y en términos fiscales genera una discrepancia entre lo declarado y lo que amparan los CFDI emitidos.

Impacto directo en la comprobación fiscal

• Como principal: el CFDI que emites ampara el valor total del producto, y la asociación de folios refleja el ingreso completo con su costo de ventas correspondiente.
• Como agente: tu CFDI ampara únicamente la intermediación; el resto del flujo transita por cuentas puente hacia el proveedor, que es quien debe expedir el comprobante al consumidor final.

4. Los costos del contrato: NIF D-2 y el postulado de asociación

Con relación al envío, el empaque especializado, las comisiones del procesador de pagos y las cuotas del marketplace no se deben registrar de forma arbitraria. La NIF D-2, Costos por contratos con clientes, distingue dos categorías: los costos incrementales para obtener un contrato es decir aquellos en los que no se habría incurrido si el contrato no se hubiera conseguido y los costos incurridos para cumplirlo. En ambos casos solo se deben reconocer como activo cuando se relacionan directamente con el contrato, generan o mejoran recursos que se usarán para satisfacer obligaciones futuras y existe expectativa razonable de recuperarlos (NIF D-2, párrafo 42.2).

En un e-commerce de alta rotación esas condiciones casi nunca se cumplen del lado del cumplimiento. El costo de fulfillment se incurre para entregar el bien y se consume en ese mismo acto: no genera un recurso que sirva para obligaciones futuras, de modo que se lleva a resultados en el periodo en que se reconoce el ingreso al que corresponde.

El tratamiento de los costos de obtención sí admite un atajo. Cuando el activo que se habría reconocido se amortizaría en un año o menos, la norma permite llevarlos a gasto desde que se incurren (NIF D-2, párrafo 41.5). En comercio electrónico, donde el ciclo completo del contrato se agota en días, ese es el escenario ordinario.

5. Tres momentos para una misma venta: devengo, acumulación y causación

A continuación vamos a detallar el problema y la razón por la que un e-commerce bien llevado contablemente podría seguir mal declarado. La misma operación tiene tres enfoques distintos:

La consecuencia operativa es que el estado de resultados y la declaración no deben cuadrar renglón por renglón, y eso está bien siempre que la diferencia sea explicable y esté documentada. Sin embargo es fundamental tener todo el soporte documental.

El caso de los anticipos

Cuando el cobro precede a la entrega, la empresa está ante un anticipo. Ese anticipo requiere su propio CFDI y su propio tratamiento de aplicación posterior, que es un tema con reglas específicas y errores costosos. Lo abordamos a detalle en nuestra entrada sobre CFDI de anticipos, a la que conviene remitir desde este artículo.

6. Contabilidad electrónica: donde el registro por lotes se rompe

Este es, en nuestra experiencia, un punto crítico. La obligación no está en discusión: el artículo 28 del Código Fiscal de la Federación establece, en su fracción III, la obligación de llevar los registros contables en medios electrónicos conforme al Reglamento del Código y a las disposiciones de carácter general que emita el SAT; y en su fracción IV, ingresar mensualmente esa información contable a través del portal del SAT.

El Reglamento del CFF, en su artículo 33, apartado B, detalla el contenido mínimo de esos registros y exige que cada operación pueda identificarse con su documentación comprobatoria, de modo que sea posible relacionar cada asiento con el comprobante fiscal que lo respalda. La Resolución Miscelánea Fiscal, a su vez, remite al Anexo 24 para definir que son archivos en extensión XML y su estructura detallando el contenido de cada nodo.

Qué pide el Anexo 24

• Catálogo de cuentas con código agrupador. Tus cuentas deben mapearse al catálogo del SAT. En e-commerce esto obliga a decidir desde el diseño cómo se separan canales, el procesador de pagos y cuentas puente.
• Balanza de comprobación. Mensual, y de cierre con los ajustes del ejercicio.
• Pólizas del periodo. Aquí está el problema: cada póliza debe permitir identificar la forma de pago, las cuentas bancarias involucradas y lo más importante el folio fiscal de los comprobantes que soportan la operación.
• Auxiliar de folios de comprobantes fiscales. El archivo que relaciona cada UUID con la póliza en la que quedó registrado. Este junto con el auxiliar de cuenta y subcuenta son fundamentales en casos de pólizas globales.
• Auxiliares de cuenta y subcuenta. El detalle de movimientos que da trazabilidad al saldo de cada cuenta, debe tenerse completo en caso de que tengas pólizas globales.

El problema concreto del batch

La mayoría de las plataformas de e-commerce y de los conectores contables generan una póliza de ingresos diaria o incluso mensual, agrupada por totales: una línea de ventas, una de IVA, una de comisiones y una de banco. Esa póliza cuadra perfectamente y, sin embargo, es insuficiente, porque no contiene el detalle de folios que exige el Anexo 24 en cuanto a pólizas del periodo.

Mientras nadie la pida, no pasa nada. El costo aparece en el momento en que la autoridad requiere la contabilidad en medios electrónicos esto ocurre de forma rutinaria en solicitudes de devolución de saldos a favor, en compensaciones, en compulsas y en revisiones electrónicas. En ese momento hay que entregar las pólizas con sus folios y los auxiliares, y reconstruir seis meses de asociación de UUID contra pólizas agrupadas es un trabajo que se mide en semanas, la alternativa que se tiene es complementar la información con los auxiliares de folios sin embargo es fundamental tener un control detallado de todos los CFDIs que compongan un batch de pólizas globales.

A esto se suma un riesgo de fondo: una contabilidad que no permite identificar cada operación con su comprobante puede considerarse no llevada conforme a las disposiciones fiscales, con las consecuencias sancionatorias previstas en el propio Código y, en el escenario más severo, abriendo la puerta a la determinación presuntiva de ingresos.

7. Devoluciones, cupones y contraprestación variable

En comercio electrónico la devolución no es una excepción: es parte del modelo de negocio. Contablemente eso significa que el precio de la transacción es variable y debe estimarse desde el reconocimiento inicial.

La NIF D-1 requiere estimar la contraprestación variable (párrafo 43.4.1) y reconocer un pasivo por reembolso por los importes que se espera devolver, así como un activo por el derecho a recuperar los productos que se espera regresen al inventario (párrafos 43.4.8 y 43.4.12). La estimación está sujeta a una restricción: solo se incluye en el ingreso el importe respecto del cual sea "altamente probable que no ocurra una reversión importante" (NIF D-1, párrafo 43.4.21).

Fiscalmente el tratamiento es distinto. La Ley del Impuesto sobre la Renta permite deducir las devoluciones, descuentos y bonificaciones en el ejercicio en que efectivamente se realizan, conforme al artículo 25, fracción I; no admite estimaciones. Y en materia de IVA, la restitución del impuesto correspondiente a la operación devuelta procede en los términos del artículo 7 de la Ley del IVA, respaldada con el CFDI de egreso correspondiente.

El resultado es otra diferencia temporal que hay que controlar y documentar. Los cupones y códigos de descuento siguen la misma lógica: reducen el precio de la transacción contablemente y deben reflejarse en el comprobante fiscal, no registrarse como un gasto de mercadotecnia.

8. Arquitectura operativa: cómo debe estar armado el ERP

Las decisiones de diseño marcan la diferencia entre una contabilidad auditable y una que hay que reconstruir cada vez que la autoridad pregunta.

Catálogo y cuentas puente

• Mapear el catálogo al código agrupador del SAT desde el diseño inicial, no como un ejercicio de última hora antes del envío mensual.
• Abrir una cuenta puente por cada procesador de pagos y por cada marketplace, del tipo «Procesador de pagos por cobrar», de modo que el bruto entre por la cuenta puente y el depósito bancario la cancele contra comisiones, retenciones, reembolsos y contracargos.
• Separar por canal: tienda propia, cada marketplace y cada punto de venta físico, si lo hay. La rentabilidad por canal es imposible de calcular si todo entra a la misma cuenta.
• Distinguir en cuentas separadas los anticipos de clientes de los ingresos reconocidos.

Pólizas y folios

• Generar la póliza de ingresos con el detalle de folios fiscales, o bien mantener una póliza agrupada acompañada del auxiliar de folios completo y conciliado.
• Automatizar la asociación de UUID desde el momento del timbrado, no reconstruirla al cierre.
• Controlar por separado el CFDI global y los CFDI nominativos, cuidando que ninguna operación quede amparada dos veces.
• Rastrear cancelaciones y CFDI de egreso con la misma disciplina que los comprobantes de ingreso.

Conciliaciones de cierre

• Conciliación de tres vías: reporte del procesador de pagos contra CFDI emitidos contra movimientos bancarios.
• Reporte mensual de pedidos cobrados y no entregados al corte, que es la base del saldo de anticipos.
• Cálculo y revisión de la estimación de devoluciones con datos históricos propios, no con supuestos genéricos.
• Conciliación entre ingreso contable, ingreso acumulable e ingreso amparado por CFDI, con explicación documentada de cada diferencia.

9. Checklist de cumplimiento

Si operas un e-commerce, estas son las preguntas cuya respuesta deberías tener por escrito:

• ¿Nuestros términos y condiciones definen con claridad en qué momento se transfiere el control del producto?
• ¿Estamos actuando como principal o como agente en cada canal, y el registro es congruente con esa conclusión?
• ¿Reconocemos el ingreso por el bruto o estamos registrando el depósito neto del procesador de pagos?
• ¿Tenemos identificado el saldo de anticipos de clientes al cierre de cada mes?
• ¿Nuestras pólizas contienen el detalle de folios fiscales o generamos el auxiliar de folios correspondiente?
• ¿Podríamos entregar pólizas y auxiliares del ejercicio si la autoridad los requiriera esta semana?
• ¿Tenemos una estimación de devoluciones sustentada en datos históricos?
• ¿Existe una conciliación documentada entre el ingreso contable, el acumulable y el amparado por CFDI?

Preguntas frecuentes

Conclusión

El reconocimiento de ingresos en comercio electrónico no es un problema de norma contable ni un problema fiscal: es un problema de diseño. Las cuatro capas —NIF D-1 y D-2, LISR, LIVA y contabilidad electrónica— tienen respuestas claras por separado. La dificultad está en que el sistema que procesa treinta mil pedidos al mes produzca, sin intervención manual, la información que las cuatro exigen al mismo tiempo.

Cuando ese diseño se hace bien desde el principio, el cierre mensual deja de ser una reconstrucción y la empresa puede responder un requerimiento de la autoridad en días en lugar de semanas. Cuando no, el costo aparece siempre: en una devolución rechazada, en una revisión electrónica o en un estado de resultados que no refleja el negocio real.