Retenciones de IVA e ISR en plataformas 2026: la guía del ingeniero para construir el cálculo y el CFDI de retenciones

Qué cambió el 1 de enero de 2026 (y a quién le pega ahora)

Si operas un marketplace en México y pagas a vendedores terceros, lee esto antes de tu próxima venta: desde el 1 de enero de 2026 quizá tú seas el retenedor. No el contador del vendedor, no el SAT por su cuenta: tu plataforma. Y eso es un problema de ingeniería, no nada más de contabilidad.

El cambio viene en la Ley de Ingresos de la Federación 2026, publicada en el DOF el 7 de noviembre de 2025, y entró en vigor el 1 de enero de 2026. Dos cosas se movieron y las dos te tocan si construyes pagos:

Primero, el régimen de plataformas digitales ahora también aplica a personas morales que venden a través de plataformas. Hasta 2025 esto golpeaba sobre todo a personas físicas; desde 2026 las empresas que venden por tu marketplace también quedan dentro. Segundo, la retención de ISR para enajenación de bienes y prestación de servicios subió del 1% al 2.5% del ingreso.

Un retenedor, en términos de ingeniero, es una plataforma o marketplace que intermedia la venta de bienes o servicios en México: debe retener ISR e IVA de cada venta del vendedor, enterarlos al SAT por cuenta del vendedor y emitirle el comprobante. Si tu plataforma cobra y luego paga al vendedor —da igual si es con Stripe Connect, split de Mercado Pago o un payout propio— el SAT te puede ver como ese retenedor.

Por qué es problema de ingeniería: la retención no es un correo que manda tu contador a fin de mes. Es lógica que tiene que vivir en el momento del payout, ramificar sobre el RFC de cada vendedor, netearse en el orden correcto y terminar en un CFDI timbrado. Todo eso lo construyes tú.

Aviso de una vez, igual que siempre: soy ingeniero, no contador. Te doy el patrón técnico exacto. El alcance (si TÚ eres el retenedor para tu caso), las tasas vigentes y los plazos exactos, confírmalos con un contador y trata todo como sujeto a cambio en 2026. Las fuentes contables ya explican las tasas bien —IDC sobre plataformas digitales 2026 y personas morales y Mercado Pago sobre las nuevas retenciones 2026—; lo que falta es el cómo construirlo.

Cuáles son las tasas: ISR 2.5%, IVA 8% — y el castigo por no tener RFC

Las tasas que tu código tiene que conocer, para enajenación de bienes y prestación de servicios (el caso e-commerce / marketplace que cubre este post):

• ISR retención = 2.5% del ingreso bruto por venta. Bruto: antes de deducciones, sin importar si el vendedor ganó o perdió en esa venta.
• IVA retención = 8%, que es el 50% del IVA del 16%.

Sumadas, en el camino con RFC válido retienes alrededor del 10.5% del bruto de cada venta. Una precisión, para que no la confundas en tu modelo: ese 10.5% es la suma nominal de ambas retenciones sobre la operación; el 8% de IVA se retiene del IVA trasladado (el 16% que paga el comprador), mientras el 2.5% de ISR sale del ingreso del vendedor. Ese número es el que va a asustar a tus vendedores; más abajo explico por qué no deberían asustarse.

Ojo grande aquí: el 2.5% no es para todas las actividades. Otras actividades tienen su propia tasa de ISR —transporte de pasajeros / entrega de bienes ronda 2.1%, hospedaje ronda 4%—. Este post cubre bienes y servicios. Si tu marketplace mueve otra actividad, confirma la tasa de TU actividad con tu contador; no copies el 2.5% a ciegas.

Y el camino que de verdad no quieres pisar a ciegas: si el vendedor no te da un RFC válido, la retención de ISR salta a 20% y la de IVA a 16% (el 100% del IVA). Ese mismo IVA de hasta el 100% aplica también a operaciones con residentes en el extranjero o depósitos en cuentas en el extranjero.

Opinión, etiquetada como tal: la validación del RFC es el paso donde los marketplaces se van a quemar. Si lo dejas como un campo opcional en el onboarding, vas a terminar reteniendo 20%/16% sin querer —o peor, reteniendo de menos y quedando tú a deber—. Hazlo una compuerta dura en el alta del vendedor, no un “luego lo pedimos”.

¿El vendedor pierde ese dinero? No — es acreditable, no un impuesto extra

Este es el malentendido que más te va a llegar a soporte, así que constrúyelo en tu producto desde el día uno: lo retenido NO es un impuesto nuevo que se traga la plataforma. Es un anticipo acreditable.

El ISR retenido es un pago provisional que el vendedor acredita en su declaración mensual y anual. El IVA retenido es acreditable en su declaración mensual de IVA. Lo único que hace tu plataforma es anticipar ese pago al SAT por cuenta del vendedor; el vendedor lo recupera como crédito.

Dicho de otro modo: el ~10.5% no desaparece. Se mueve del bolsillo del vendedor al SAT antes de tiempo, y el vendedor lo recupera al declarar. Tu plataforma no “se queda” con nada de eso; solo es el conducto.

Nota práctica de builder: por esto importa tu CFDI de retenciones + la constancia. Son la prueba del vendedor para reclamar el crédito. Si no emites bien ese documento, el vendedor sí pierde el dinero —no porque tú te lo quedaste, sino porque no tiene con qué acreditarlo—. Tu plomería fiscal es, literalmente, lo que le permite recuperar su retención.

¿Eres retenedor o no? Sobre qué tiene que ramificar tu código

La lógica de decisión, en orden:

Paso 1 — ¿eres tú el retenedor para este vendedor? Esto es: intermedias la venta y le pagas al vendedor. Es una pregunta de alcance fiscal; el caso general es sí, pero confírmalo con tu contador para tu operación.

Paso 2 — recolecta y VALIDA el RFC + régimen de cada vendedor en el onboarding. Este es el dato del que cuelga todo lo demás.

Paso 3 — ramifica la tasa por venta:

• Rama A (RFC válido): retienes 2.5% ISR + 8% IVA sobre la base correcta.
• Rama B (sin RFC válido): retienes 20% ISR + 16% IVA — el camino de castigo que no quieres tragarte sin querer.

Tu código tiene que guardar el estado de validación del RFC + el régimen por vendedor y elegir el set de tasas por venta según ese estado. No es un cálculo global: es por vendedor, evaluado en cada payout.

El siguiente código es ilustrativo — la validación real del RFC va contra el SAT o tu PAC; aquí muestro la forma, confirma las reglas vigentes.

// Ilustrativo — valida el RFC + régimen del vendedor en el onboarding.
// La validación "de verdad" se hace contra el SAT o tu PAC (lista 69-B incluida).

// Formato del RFC: persona moral (12) o persona física (13).
const RFC_RE = /^([A-ZÑ&]{3,4})\d{6}[A-Z0-9]{3}$/;

export async function validarVendedorOnboarding(seller) {
  const rfc = (seller.rfc || "").trim().toUpperCase();

  // 1. Formato básico antes de gastar una llamada al PAC
  if (!RFC_RE.test(rfc)) {
    return { rfcValido: false, motivo: "formato_invalido" };
  }

  // 2. Validación real: RFC + régimen + CP contra el SAT vía tu PAC.
  //    Confirma los nombres de campo con la API de tu PAC.
  const check = await pac.taxpayers.validate({
    tax_id: rfc,
    tax_system: seller.regimen,   // régimen fiscal del vendedor
    zip: seller.cp,
  });

  // 3. Compuerta dura: si no coincide con su CSF o cae en 69-B, NO es válido.
  if (!check.valid || check.blacklisted_69b) {
    return { rfcValido: false, motivo: check.reason };
  }

  return { rfcValido: true, rfc, regimen: seller.regimen };
}

La idea: un vendedor sin rfcValido: true no debería poder activarse para vender, o al menos no sin saber que cae en la rama de castigo del 20%/16%. Esa es la compuerta.

¿Cómo calcular y netear la retención? (el truco del orden de operaciones)

Aquí está el moat operativo, el detalle que las fuentes contables no te cuentan porque no construyen payouts: el orden de operaciones.

La retención sale del bruto del vendedor ANTES de tu comisión de marketplace / application_fee de Connect. No después. Si inviertes el orden, el vendedor termina cobrando de más o de menos y tu conciliación no cuadra.

Es exactamente la misma clase de gotcha que “la comisión de Mercado Pago se descuenta antes que tu application_fee”, que ya cubrí en split payments con Mercado Pago. El cálculo no es difícil; lo difícil es ponerlo en el lugar correcto del pipeline.

Primero, la calculadora de retención. Devuelve los montos a netear y elige el set de tasas según el RFC:

// Ilustrativo — calculadora de retención para ENAJENACIÓN DE BIENES
// Y PRESTACIÓN DE SERVICIOS. Otras actividades tienen su propia tasa de ISR
// (transporte ~2.1%, hospedaje ~4%): confirma la de TU actividad.

const TASAS = {
  validRFC:   { isr: 0.025, iva: 0.08 },  // 2.5% ISR + 8% IVA (mitad del 16%)
  noValidRFC: { isr: 0.20,  iva: 0.16 },  // castigo: 20% ISR + 16% IVA
};

// gross = ingreso BRUTO de la venta, en centavos, antes de cualquier comisión.
export function calcularRetencion({ gross, rfcValido }) {
  const t = rfcValido ? TASAS.validRFC : TASAS.noValidRFC;

  const isr = Math.round(gross * t.isr);
  const iva = Math.round(gross * t.iva);

  return {
    isr,
    iva,
    totalRetenido: isr + iva,
    rama: rfcValido ? "validRFC" : "noValidRFC",
  };
}

Y ahora el paso que importa: netearla en el orden correcto dentro del payout. La retención sale del bruto antes de tu comisión. Sobre el pipeline de payouts de Connect del que descuentas todo esto, escribí la base en pagos de marketplace con Stripe Connect.

// Ilustrativo — netear la retención de un payout de Connect / split.
// ORDEN: bruto − retención (al SAT) − comisión marketplace = lo que recibe el vendedor.

export function armarPayout({ gross, rfcValido, marketplaceFee }) {
  // 1. PRIMERO la retención, sobre el bruto.
  const ret = calcularRetencion({ gross, rfcValido });

  // 2. DESPUÉS tu comisión de marketplace.
  //    Si la calcularas antes que la retención, el neteo queda mal.
  const netVendedor = gross - ret.totalRetenido - marketplaceFee;

  return {
    gross,
    retencionSAT: ret.totalRetenido,  // lo que enteras al SAT por el vendedor
    isr: ret.isr,
    iva: ret.iva,
    marketplaceFee,                   // tu application_fee
    netVendedor,                      // lo que de verdad recibe el vendedor
  };
}

// Ejemplo: venta de $1,000.00 (100000 centavos), RFC válido, comisión 10%.
// comisión = 10% del bruto = 100.00 (confirma la base de tu application_fee:
//            sobre el bruto vs. sobre el neto — suele ser configurable).
// retención = 105.00 (25.00 ISR + 80.00 IVA) → SAT
// comisión  = 100.00 → tú
// vendedor recibe = 1000 − 105 − 100 = 795.00

Si el vendedor cae en la rama sin RFC válido, ese mismo armarPayout le retiene 20%/16% —y verá una mordida mucho más grande en su payout—. Razón de más para que la compuerta del RFC esté antes de la primera venta.

¿Cómo emitir el CFDI de retenciones con tu PAC?

Cerraste el cálculo y el neteo. Falta el documento. Aquí hay un detalle que confunde a todo dev que ya timbra CFDIs de venta: el CFDI de retenciones es un tipo de CFDI DISTINTO al CFDI de ingreso de la venta.

La plataforma debe emitir un CFDI de retenciones e información de pagos: detalla el ISR + IVA retenidos y va acompañado de la constancia para el vendedor. No es el mismo comprobante que el de ingreso de la venta; es otro tipo, con su propio sello.

La buena noticia para tu backend: es la misma plomería de PAC que ya usas para tus CFDIs de venta —el mismo flujo de timbrado que documenté en facturación CFDI automática con Stripe y Mercado Pago—, solo cambia el tipo de CFDI y los campos. Si ya timbras ingresos, ya tienes el 80% de la integración.

Sobre el plazo (reportado, confírmalo): la constancia / CFDI se emite el mes siguiente —algunas fuentes dicen dentro de los primeros ~5 días— y se reporta al SAT mensualmente. Trata ese plazo como sujeto a cambio y confirma el vigente en 2026 con tu contador.

La forma de la petición a un PAC, claramente ilustrativa — confirma los nombres de campo exactos con la API de tu PAC, que para retenciones suele ser distinta a la de ingresos:

// Ilustrativo — la FORMA de un CFDI de retenciones e información de pagos.
// Tipo de CFDI distinto al de ingreso. Confirma los campos con tu PAC.

const cfdiRetencion = await pac.retentions.create({
  // Emisor: tu plataforma (el retenedor)
  issuer: { tax_id: process.env.RFC_PLATAFORMA },

  // Receptor: el vendedor al que le retuviste
  receiver: {
    tax_id: seller.rfc,          // RFC validado del vendedor
    tax_system: seller.regimen,
  },

  // Clave que identifica el tipo de retención (plataformas tecnológicas).
  // Confirma la clave vigente del catálogo del SAT con tu PAC.
  retention_key: "...",

  period: { month: 6, year: 2026 },

  // Montos retenidos en el periodo (los que calculaste y neteaste)
  totals: {
    isr_retenido: 25.0,   // 2.5% del bruto
    iva_retenido: 80.0,   // 8% del bruto (mitad del 16%)
  },
});

// Te regresa el XML timbrado del CFDI de retenciones + la constancia.
await guardarConstancia(seller.id, cfdiRetencion.uuid, cfdiRetencion.xml_url);
await enviarConstancia(seller.email, cfdiRetencion.pdf_url);

Me mantengo vendor-neutral en PACs: el patrón es portable entre proveedores. Elige por DX y precio, no por marketing. El CFDI de retenciones es otra obligación de timbrado obligatoria del SAT, en la misma familia que el Carta Porte para desarrolladores si tu operación también mueve mercancía.

El build de punta a punta: del onboarding al entero mensual

Junta todo el pipeline en cinco pasos. Este es el orden que seguiría en producción:

1. Valida el RFC + régimen en el onboarding. Compuerta dura, no un campo opcional. Sin RFC válido, el vendedor sabe que cae en la rama 20%/16%.
2. Calcula la retención por venta (2.5%/8% o el fallback 20%/16%) sobre la base correcta.
3. Netéala del payout ANTES de tu comisión de marketplace. El orden de operaciones es donde se rompe la conciliación.
4. Emite el CFDI de retenciones vía tu PAC —tipo de CFDI distinto, misma plomería que tus CFDIs de venta—.
5. Reconcilia, entera al SAT y emite la constancia, mensual.

Opinión, etiquetada: la compuerta de validación del RFC es lo de mayor palanca que puedes construir primero. Todo lo demás —el cálculo, el neteo, el CFDI— depende de ese dato. Si el RFC entra mal, todo lo que sigue retiene mal.

Y otra vez, claro: soy ingeniero, no contador. El alcance (si eres el retenedor), las tasas por actividad y los plazos exactos, a tu contador y tu área de cumplimiento. Tú pones la plomería técnica; ellos ponen el criterio fiscal.

Preguntas frecuentes: tasas, plazos y casos borde

¿Esto aplica a personas morales ahora? Sí, desde el 1 de enero de 2026 (LIF 2026, DOF 7-nov-2025). Hasta 2025 pegaba sobre todo a personas físicas; ahora también a empresas que venden por plataformas.

¿El 2.5% de ISR es para toda actividad? No. Es para bienes y servicios. Transporte ronda ~2.1%, hospedaje ~4%, y difieren. Confirma la tasa de TU actividad con tu contador.

¿Qué pasa si un vendedor no tiene RFC válido? La retención salta a ISR 20% / IVA 16%. Ramifica tu código sobre ese estado y haz del RFC una compuerta dura en el onboarding.

¿El vendedor pierde ese dinero? No: es acreditable. El ISR es un pago provisional y el IVA es acreditable en su declaración mensual. La plataforma solo lo anticipa al SAT; el vendedor lo recupera como crédito —con tu constancia como prueba—.

¿Qué CFDI emito? Un CFDI de retenciones e información de pagos, distinto del CFDI de ingreso de la venta, más la constancia para el vendedor.

¿Cuándo se emite? Reportado como el mes siguiente —algunas fuentes dicen dentro de los primeros ~5 días— y se reporta al SAT mensual. Confirma el plazo vigente en 2026.

¿Soy retenedor con seguridad? Eso es una pregunta de alcance fiscal. Confírmalo con tu contador para tu operación específica.

Cierre: construye la compuerta antes de la primera venta

Las fuentes contables explican las tasas; el trabajo de ingeniería es el pipeline: validar, calcular, netear, emitir, enterar. Ese es el moat que ningún blog de PAC te da.

Construye la compuerta de validación del RFC antes de tomar tu primer peso. Es lo de mayor palanca y lo que evita que retengas 20%/16% sin querer —o que retengas de menos y quedes tú a deber—. Después, el cálculo y el neteo en el orden correcto, y el CFDI de retenciones sobre la misma plomería de PAC que ya tienes.

Y el recordatorio que no caduca: soy ingeniero, no contador. Las tasas, los plazos y el alcance los define el SAT y cambian. Trata todo como vigente en 2026 y confírmalo con tu contador y tu PAC antes de moverlo a producción.

Más sobre la capa fiscal mexicana en el hub de CFDI y facturación.

Fuentes oficiales: IDC — plataformas digitales 2026 y personas morales · Mercado Pago — nuevas retenciones 2026 · SAT · Ley de Ingresos de la Federación 2026 (DOF 7-nov-2025, confirma la versión vigente)