Elementos de Apoyo · Self Service
Errores Comunes
Casos frecuentes de soporte con solución paso a paso — sin necesidad de abrir un ticket.
Soluciones más buscadas
Mostrando 6 de 9 temas
Julio 2026
Mi RFC está activo y el CSD vigente, pero sigo recibiendo Error 402
El Error 402 indica que el RFC no tiene la validez de obligaciones necesaria en la LCO, aunque esté activo ante la autoridad. Esto es diferente al estatus del RFC y solo puede resolverlo el contribuyente directamente.
Frecuencia
Muy frecuente
Mensaje de error
Error 402 — RFC del emisor no se encuentra en
el régimen de contribuyentes (LCO).
Detalle: El certificado debe contar con validez
de obligaciones dentro de la lista LCO.
Pasos para resolverlo
1Verifica el RFC y CSD con Validador SAT para RFC y Validar CSD. Si ambos están activos y el error persiste, el problema es la validez de obligaciones.
2Si el error apareció de un día para otro: puede ser un desfase de sincronización en la LCO. Espera a que se registre una nueva actualización — puedes consultar la última en la página de inicio de developers.sw.com.mx — y vuelve a intentarlo.
3Si ya pasaron varios días: el RFC tiene valor 0 en validez de obligaciones. El emisor debe acudir con la autoridad para actualizar su situación fiscal.
4Consulta el estatus de la LCO en tiempo real en la página de inicio de developers.sw.com.mx.
Para más detalle sobre validez de obligaciones consulta el video TIPS-DEVS | Código de Error 402 — RFC del emisor no se encuentra en las listas LCO. También puedes consultar el estatus y la última actualización de la LCO directamente en la página de inicio de developers.sw.com.mx.
Julio 2026
Mis descargas masivas en Efisco llevan días “En proceso” o regresan vacías
El servicio de descarga masiva está presentando intermitencias y lentitud. Las peticiones pueden tardar más de lo habitual o regresar vacías aunque sí exista información en el rango solicitado.
Frecuencia
Muy frecuente
¿Por qué ocurre?
Cuando el servicio presenta lentitud:
→ Las peticiones quedan “En proceso” por
más tiempo del usual
→ Algunas regresan vacías aunque haya
información en ese rango de fechas
→ La tasa de respuesta puede bajar
significativamente
Esto no está relacionado con tu cuenta
ni con la configuración de Efisco.
Recomendaciones
1Divide las peticiones en rangos cortos — en lugar de solicitar un mes completo, divide por quincenas o periodos de 15 días. Menor volumen por petición = mayor probabilidad de éxito.
2Si una petición regresó con error o vacía, genera una nueva petición con el mismo rango — no reutilices la petición anterior. Cada petición es independiente.
3Monitorea la tasa de respuesta en el portal de Efisco antes de generar nuevas peticiones — si la tasa está baja, espera a que mejore para evitar peticiones fallidas.
4Verifica que tu FIEL esté vigente en el aplicativo Efisco — una FIEL revocada o vencida genera errores en las descargas aunque la lentitud no sea el problema. Carga la FIEL actualizada si es necesario.
5Las peticiones en proceso no se pueden cancelar, pero son independientes a las nuevas — puedes generar nuevas peticiones sin afectar las que ya están en curso.
Si llevas varios días sin respuesta y ya aplicaste las recomendaciones, abre un ticket a soporte@sw.com.mx — el equipo puede monitorear tus peticiones específicas y confirmarte si están avanzando o requieren reintento.
Julio 2026
Se me agotaron los timbres de prueba — ¿cómo obtengo más?
Los timbres del ambiente sandbox no tienen costo pero tienen un límite inicial. Si necesitas más timbres de prueba para continuar con tu integración, puedes solicitarlos al equipo de soporte.
Frecuencia
Frecuente
Pasos para resolverlo
1Confirma que tu saldo de prueba llegó a cero revisando el portal de pruebas — sección de saldo de timbres.
2Escribe a soporte@sw.com.mx o abre un ticket indicando: tu usuario sandbox, el RFC con el que estás probando y el número de timbres adicionales que necesitas para completar tu validación.
3Los timbres de prueba no representan un costo adicional y se asignan manualmente por el equipo de ventas — no hay proceso automático de recarga.
Los timbres del ambiente sandbox no tienen costo ni representan consumo productivo — son exclusivamente para pruebas, por ello son limitados. Una vez en producción, tus timbres reales son independientes y se contratan por separado.
Julio 2026
Soy integrador de una cuenta SW activa — ¿cómo obtengo credenciales de prueba propias?
Cuando un integrador o desarrollador trabaja para un cliente que ya tiene cuenta productiva en SW, puede solicitar credenciales sandbox propias para desarrollar y probar sin afectar el ambiente de producción del cliente.
Frecuencia
Frecuente
Pasos para resolverlo
1Abre un ticket de soporte indicando: el RFC del cliente activo para el que estás integrando, el correo al que necesites que se ligue la cuenta de pruebas, y que necesitas credenciales sandbox para desarrollo.
2El equipo generará las credenciales de prueba y te las enviará al correo registrado — el proceso tarda normalmente menos de un día hábil.
3Usa esas credenciales exclusivamente en
services.test.sw.com.mx o api.test.sw.com.mx — no uses las credenciales productivas del cliente, ya que se generará un error de autenticación.Las credenciales sandbox son independientes a las productivas del cliente — puedes hacer todas las pruebas que necesites sin riesgo de consumir timbres reales ni afectar la operación del cliente.
Julio 2026
¿Se puede cancelar un Complemento de Pago (REP) ya timbrado?
Duda fiscal frecuente: cuando se emitió un REP con datos incorrectos o el pago no se realizó, ¿es posible cancelarlo? Técnicamente sí es posible, pero el proceso tiene consideraciones fiscales importantes.
Frecuencia
Frecuente
¿Qué dice la autoridad?
Técnicamente: sí se puede cancelar un REP.
Sin embargo, hay consideraciones fiscales:
→ Al cancelar el REP, la factura original
regresa a estatus PPD pendiente de pago
→ Si el pago sí ocurrió, debes emitir
un nuevo REP con los datos correctos
→ Si el pago NO ocurrió, cancela el REP
y queda la factura original en PPD
Recomendación: consulta con tu área fiscal
antes de cancelar un REP para evitar
inconsistencias contables.
Pasos para cancelarlo
1La cancelación de un REP sigue el mismo proceso que cualquier CFDI — usa Motivo 01 si emitirás uno nuevo con los datos correctos, o Motivo 03 si el pago no ocurrió.
2Si usas Motivo 01: timbra primero el REP correcto con
TipoRelacion="04" apuntando al UUID del REP a cancelar, luego cancela el original.3Verifica el estatus de la cancelación en el portal de verificación ingresando el UUID del REP.
Cancelar un REP no cancela la factura original — solo elimina la constancia de pago. La factura vuelve a quedar en PPD pendiente. Asesórate con tu contador antes de proceder si tienes dudas sobre el impacto contable.
Julio 2026
Error al timbrar — la razón social tiene el símbolo “&” y el XML falla después del sellado
El error ocurre cuando el XML es modificado después de ser sellado. El símbolo “&” en la razón social u otros campos debe estar codificado como
& en el XML antes de sellarlo — cualquier modificación posterior invalida la cadena original.Frecuencia
Frecuente
La causa del error
El error se presenta cuando el XML es
modificado DESPUÉS del sellado.
La cadena original se genera a partir del
XML sellado — si algo cambia después, la
cadena ya no coincide y el timbrado falla.
El estándar técnico del SAT ya define las
secuencias de escape para XML obligatorias:
& para &
< para <
> para >
" para “
Pasos para resolverlo
1Asegúrate de aplicar las secuencias de escape definidas en el estándar técnico antes de sellar el XML — no después. El símbolo
& en la razón social debe codificarse como & en el XML antes del sellado.2Revisa tu proceso: el flujo correcto es 1) construir XML con caracteres correctamente codificados, 2) sellar, 3) enviar a timbrar. No modifiques el XML entre el sellado y el timbrado.
3Valida tu XML con Validar CFDI 4.0 antes de sellarlo para detectar caracteres no codificados.
Una librería XML estándar codifica automáticamente los caracteres especiales al construir el nodo — si estás armando el XML como string concatenado, ese es el origen del problema. Usa siempre un parser XML para construir el documento.
Julio 2026
¿Cuáles son las URLs actuales para timbrar retenciones? El servicio me da error de conexión
Las URLs del servicio de timbrado de retenciones son diferentes a las del timbrado CFDI estándar. Si recibes error de conexión, verifica que estés usando el endpoint correcto para tu ambiente.
Frecuencia
Frecuente
Endpoints de retenciones
URL base:
Pruebas: services.test.sw.com.mx
Producción: services.sw.com.mx
Timbrado Retenciones:
/retencion/stamp/{version}
/retencion/stamp/json/{version}/{format}
Emisión Timbrado Retenciones:
/retencion/issue/{version}
/retencion/issue/json/{version}/{format}
Pasos para resolverlo
1Verifica que la URL base corresponda a tu ambiente — pruebas usa
services.test.sw.com.mx y producción usa services.sw.com.mx o api.sw.com.mx.2Consulta la documentación completa según el servicio que uses: Timbrado Retenciones o Emisión Timbrado Retenciones — cada uno tiene paths y versiones específicos.
3El path de retenciones es diferente al de CFDI estándar
/cfdi33/stamp/{version} — no son intercambiables. Asegúrate de usar el path correcto para retenciones.El token de autenticación y las credenciales son los mismos para retenciones y CFDI estándar — solo cambia el endpoint. No necesitas una cuenta diferente para timbrar retenciones.
Julio 2026
El XML de respuesta trae caracteres extraños en el nombre del receptor
Al procesar la respuesta del servicio, algunos sistemas muestran caracteres extraños en nombres con acentos o caracteres especiales. Esto ocurre cuando el encoding al leer la respuesta no coincide con el UTF-8 en que se devuelve el XML.
Frecuencia
Frecuente
¿Por qué ocurre?
El XML de respuesta viene en UTF-8.
Si tu sistema lo procesa con otro encoding
(ISO-8859-1, Latin-1) los caracteres
especiales pueden verse así:
á → á | é → é | ñ → ñ
Asegúrate de leer la respuesta en UTF-8
para que los caracteres se muestren bien.
Pasos para resolverlo
1Asegúrate de que tu sistema lee la respuesta HTTP en UTF-8 — verifica el encoding al parsear el JSON o XML de respuesta.
2Si usas un cliente HTTP, establece explícitamente el charset:
Content-Type: application/json; charset=utf-8 tanto en el request como al procesar el response.3Verifica el XML timbrado original descargándolo directamente desde el portal SW o con el servicio de recuperación por UUID — si se ve bien ahí, el problema es tu proceso de lectura.
Puedes validarlo fácilmente: descarga el XML desde el portal SW o consúltalo con el servicio de recuperación por UUID. Si se ve bien ahí, solo necesitas ajustar el encoding en tu proceso de lectura a UTF-8.
Junio 2026
Tengo credenciales de prueba pero no puedo timbrar — ¿qué más necesito configurar?
Al intentar timbrar en el ambiente de pruebas, el servicio regresa error de certificado porque la cuenta sandbox no tiene cargado ningún CSD. Sin certificado, no es posible timbrar aunque las credenciales sean correctas.
Frecuencia
Muy frecuente
Pasos para resolverlo
1Descarga los CSD de pruebas vigentes desde el portal SW — son certificados especiales para el ambiente sandbox, diferentes a tu CSD productivo.
2Entra al portal de pruebas portal.test.sw.com.mx con tus credenciales sandbox y carga el CSD descargado en la sección de Emisores.
3Una vez cargado el CSD, vuelve a intentar el timbrado. Si tu integración usa el RFC del CSD de pruebas, asegúrate de que coincida con el que configuraste en tu request.
4Para Carta Porte en sandbox: usa exactamente el RFC del CSD de pruebas que descargaste — no el RFC de tu empresa, ya que en pruebas usas certificados ficticios proporcionados por SW.
Los CSD de pruebas tienen fecha de expiración. Si antes timbrabas bien en sandbox y de repente fallas, verifica que el CSD de pruebas siga vigente — puede necesitar actualizarse.
Junio 2026
AU2000 — Mis credenciales son correctas pero el servicio me regresa usuario o contraseña inválidos
Error AU2000 aunque las credenciales parecen correctas. La causa más frecuente es mezclar credenciales de un ambiente con el endpoint del otro — cada ambiente tiene su propio usuario, contraseña y URL de autenticación.
Frecuencia
Muy frecuente
Credenciales y endpoints por ambiente
PRUEBAS:
Autenticación: services.test.sw.com.mx
/v2/security/authenticate
Portal: portal.test.sw.com.mx
Credenciales: las de tu cuenta sandbox
PRODUCCIÓN:
Autenticación: services.sw.com.mx (v1)
api.sw.com.mx (v2)
/v2/security/authenticate
Portal: portal.sw.com.mx
Credenciales: las de tu cuenta productiva
⚠ Mezclar credenciales genera AU2000.
Pasos para resolverlo
1Verifica qué endpoint estás usando y que las credenciales correspondan a ese ambiente. Si apuntas a
services.test.sw.com.mx usa credenciales de pruebas; si apuntas a services.sw.com.mx o api.sw.com.mx usa credenciales de producción.2Valida tus credenciales entrando directamente al portal correspondiente — si puedes entrar, las credenciales son correctas y el problema está en la URL del endpoint.
3Si no tienes credenciales de prueba, solicítalas en Ambiente de pruebas — son independientes a las productivas.
Una forma rápida de identificar el problema: si el usuario de producción termina en
@tuempresa.com y lo estás usando en el endpoint de pruebas, ese es el error — cada cuenta existe solo en su propio ambiente.
Junio 2026
¿Cuáles son las URLs actuales de los servicios de SW? Necesito actualizar mis apuntadores
SW actualizó sus endpoints. Si tu sistema aún apunta a URLs anteriores como
advans.com necesitas actualizarlas a las direcciones actuales para evitar errores de conexión.Frecuencia
Frecuente
URLs actuales
PRUEBAS:
Timbrado: services.test.sw.com.mx
Cancelación: services.test.sw.com.mx
Auth: services.test.sw.com.mx
/v2/security/authenticate
PRODUCCIÓN (dos dominios disponibles):
services.sw.com.mx ← dominio principal
api.sw.com.mx ← dominio alternativo
Auth: /v2/security/authenticate
Ambos dominios productivos son válidos.
Solo cambia la URL base — token y
credenciales siguen igual.
Pasos para resolverlo
1Localiza en tu sistema o configuración la URL base del servicio SW y reemplázala por la URL actual correspondiente a tu ambiente.
2El cambio es solo en la URL base — el path del endpoint, el token y las credenciales no cambian. No necesitas regenerar token ni actualizar credenciales.
3Prueba con una petición de autenticación después del cambio para confirmar que la conexión es exitosa antes de reanudar el timbrado.
Si tienes múltiples servicios configurados (timbrado, cancelación, consulta de estatus), actualiza todos. En producción puedes usar
services.sw.com.mx o api.sw.com.mx — ambos son válidos. En pruebas usa siempre services.test.sw.com.mx.
Junio 2026
CACFDI33 / CA305 — Error de certificado inválido al solicitar una cancelación
Al cancelar un CFDI aparece el error CACFDI33 con detalle CA305 — certificado inválido. Puede deberse al tipo de certificado, su vigencia o que se está usando la e.firma en lugar del CSD para la cancelación.
Frecuencia
Frecuente
Causas del error
CACFDI33 — CA305 — Certificado inválido:
Causa 1: Certificado vencido
→ El CSD expiró desde la emisión del CFDI
Causa 2: Tipo de certificado incorrecto
→ Se usa e.firma (FIEL) en lugar del CSD
Causa 3: CSD no corresponde al RFC emisor
→ El certificado es de otro RFC
Pasos para resolverlo
1Valida la vigencia y tipo del certificado con Validar CSD — confirma que es un CSD (no e.firma) y que no está vencido.
2Aunque el CSD esté vencido al momento de cancelar, la cancelación debe seguir siendo posible. Si el error persiste con un CSD vigente del mismo RFC, el problema puede ser el tipo de certificado — asegúrate de no estar enviando la e.firma.
3Verifica que el RFC del CSD que envías en la cancelación sea el mismo RFC emisor del CFDI que intentas cancelar.
4Si el error persiste después de verificar todo lo anterior, abre un ticket adjuntando el XML de la solicitud de cancelación para revisión manual.
La e.firma y el CSD son certificados diferentes — la e.firma sirve para trámites ante la autoridad, el CSD es exclusivamente para sellar y cancelar CFDI. Verifica cuál estás usando antes de intentar la cancelación.
Junio 2026
No encuentro el manifiesto de términos en el ADT — ¿dónde está?
El manifiesto de términos y condiciones del servicio está en el ADT dentro de la sección de Emisores. Aparece solo cuando hay términos pendientes de firma — si no lo ves, ya fue firmado anteriormente.
Frecuencia
Frecuente
Pasos para encontrarlo
1Entra al portal SW con tu cuenta administradora — el manifiesto solo aparece desde la cuenta principal, no desde cuentas hijas.
2Ve a la sección de Emisores en el menú del ADT. Del lado derecho de cada emisor verás una pequeña flecha o ícono — haz clic ahí para ver las opciones del emisor incluyendo el manifiesto.
3Si el manifiesto no aparece en la lista, ya fue firmado anteriormente. No es necesario firmarlo de nuevo a menos que el sistema te lo solicite explícitamente.
4Si el RFC de tu empresa no aparece en la lista de Emisores, verifica que esté dado de alta en tu cuenta — necesitas agregarlo primero para que aparezca el manifiesto.
El manifiesto se firma una sola vez por emisor. Si migraste de cuenta o cambiaste de administrador y no lo encuentras, es posible que ya esté firmado en la cuenta anterior — contacta a soporte para verificar el estatus.
Junio 2026
Mi CFDI de Comercio Exterior falla al timbrar y no identifico el error en los importes
El complemento de Comercio Exterior falla al timbrar por inconsistencias en el manejo de decimales en los campos de cantidad o importe. Un decimal extra o mal redondeado puede hacer que la validación rechace el CFDI.
Frecuencia
Frecuente
Causas frecuentes
Comercio Exterior valida aritmética estricta:
– Decimales extra en CantidadAduana
Ej: 10.000001 en lugar de 10.00
– ValorUnitarioAduana no cuadra con
el importe total declarado
– Más de 6 decimales en los importes
(el estándar permite hasta 6)
– Redondeo diferente al esperado por
la autoridad en la conversión de moneda
Pasos para resolverlo
1Revisa los campos numéricos del complemento CCE — especialmente
CantidadAduana, ValorUnitarioAduana y ValorDolares. Asegúrate de que no tengan más de 6 decimales.2Verifica que el cálculo
CantidadAduana × ValorUnitarioAduana dé exactamente el valor declarado en los importes — sin diferencias por redondeo.3Compara tu XML contra el ejemplo de CCE del catálogo de ejemplos para confirmar que los tipos de dato son correctos.
4Valida tu XML con Validar CFDI 4.0 antes de timbrar — detecta errores aritméticos antes de consumir un timbre.
El error de decimales en CCE suele aparecer cuando el sistema genera los valores con aritmética de punto flotante. Usa siempre redondeo explícito a 2 o 6 decimales según el campo antes de armar el XML.
Junio 2026
¿Es correcto emitir una factura a público en general con método PPD y forma de pago 99?
Duda fiscal frecuente: al facturar a público en general con RFC
XAXX010101000, ¿es válido usar PPD (pago en parcialidades) con forma de pago 99 (por definir)?Frecuencia
Frecuente
Respuesta
Técnicamente timbrará — la validación del
servicio lo permite.
Sin embargo, NO es correcto fiscalmente:
– RFC XAXX (público en general) implica que
no se conoce al receptor
– PPD requiere emitir Complemento de Pago
(REP) al recibir el pago
– El REP no puede emitirse a XAXX porque
requiere datos del receptor
Recomendación: usa MetodoPago=”PUE” y
FormaDeP=la real al momento de la operación.
¿Cuándo usar RFC genérico?
1Usa
XAXX010101000 solo para operaciones de público en general donde no se requiere identificar al receptor — típicamente para factura global o ventas al menudeo.2Para estas operaciones usa siempre
MetodoPago="PUE" (pago en una sola exhibición) — así no generas obligación de emitir REP.3Si el cliente pagará a crédito o en parcialidades, necesitas su RFC real para poder emitir el Complemento de Pago correctamente — no uses XAXX en ese caso.
Si tienes dudas sobre la correcta configuración fiscal de tus CFDI, consulta con tu contador o área fiscal — SW puede timbrar el documento técnicamente correcto, pero la validez fiscal depende de los datos que uses.
Junio 2026
¿Puedo timbrar con varios RFC emisores desde una sola cuenta sin configuración adicional?
Una duda frecuente al integrar: si se necesita una cuenta o configuración especial para poder timbrar CFDI de diferentes RFC emisores desde una misma cuenta SW.
Frecuencia
Frecuente
¿Cómo funciona Multi-RFC en SW?
Los timbres de SW son Multi-RFC por default:
✓ No requiere activación especial
✓ No requiere una cuenta por empresa
✓ Desde una sola cuenta puedes timbrar
CFDI de diferentes RFC emisores
Solo necesitas:
→ Cargar el CSD de cada RFC en tu cuenta
→ Enviar el RFC correcto en cada request
Pasos para configurarlo
1Entra al portal SW con tu cuenta administradora y ve a la sección Emisores.
2Agrega cada RFC que necesites timbrar y carga su CSD correspondiente. Cada emisor necesita su propio certificado vigente.
3En tu integración, asegúrate de enviar el RFC correcto en el atributo
Emisor.Rfc del CFDI — el servicio seleccionará automáticamente el CSD correspondiente.4Si necesitas separar los timbres por empresa o dar acceso independiente a cada RFC, usa cuentas hijas desde el ADT — cada una tiene su propio saldo y acceso.
No hay límite de RFC por cuenta — puedes agregar todos los emisores que necesites. El saldo de timbres es compartido entre todos los RFC de la cuenta, a menos que uses cuentas hijas con saldo asignado individualmente.
Mayo 2026
Mi RFC está activo y el CSD vigente, pero sigo sin poder timbrar — Error 402
El RFC existe y el CSD está vigente, pero el SAT rechaza el timbrado porque el RFC no tiene registrada la validez de obligaciones para emitir CFDI. Esto es diferente al estatus activo — es un campo separado que solo aparece en la LCO privada que el SAT comparte con los PAC.
Frecuencia
Muy frecuente
Mensaje de error
Error 402 — RFC del emisor no se encuentra en el
régimen de contribuyentes (LCO).
Detalle: El certificado debe contar con validez
de obligaciones dentro de la lista LCO.
¿Por qué pasa si mi RFC está activo?
La LCO valida un campo llamado “validez de
obligaciones” (Anexo 29 RMF vigente, pág. 6):
Valor 0 = sin obligaciones para emitir CFDI
Valor 1-4 = habilitado para facturar
Este campo es DISTINTO a:
x Estatus activo del RFC (visible en portal SAT)
x Fecha de vigencia del CSD
x Validación pública de clave RFC
Solo el SAT puede actualizarlo.
SW no tiene control sobre este valor.
Pasos para resolverlo
1Verifica primero que el RFC y el CSD estén vigentes con el Validador SAT para RFC y Validar CSD. Si ambos están bien y el error persiste, el problema es de validez de obligaciones.
2Si el error apareció de un día para otro y antes timbrabas sin problema: puede ser un desfase de sincronización. Espera a la siguiente actualización de la LCO — el SAT las realiza a las 12:00 de la noche — y vuelve a intentarlo.
3Si ya pasaron varios días y el error persiste: el RFC del emisor tiene valor 0 en validez de obligaciones. El emisor debe acudir al SAT para actualizar sus obligaciones fiscales. Una vez que el SAT lo actualice, el timbrado se reanudará en la siguiente actualización nocturna de la LCO.
4Consulta el estatus y horario de la última actualización de la LCO en la página de inicio de developers.sw.com.mx — sección Actualización de la LCO.
Más información: video tipSW® — Validación de datos fiscales en LRFC y LCO y el Anexo 29 RMF vigente (pág. 6).
Mayo 2026
El QR de Carta Porte no abre el portal de validación o redirige a una página de acceso
Al escanear el código QR del complemento Carta Porte 3.1 o al acceder directamente al link de verificación, el portal redirige a una pantalla de inicio de sesión o muestra un mensaje de acceso denegado, sin poder validar el documento.
Frecuencia
Frecuente
¿Qué está pasando?
El portal específico de validación de Carta Porte:
https://verificacfdi.facturaelectronica.sat.gob.mx
/verificaccp/default.aspx?idCCP=…
Actualmente presenta intermitencias — redirige
a pantalla de login o muestra acceso denegado
incluso al iniciar sesión.
Esto NO significa que tu CFDI esté mal timbrado.
El timbrado y la información del documento
se generaron y enviaron correctamente.
¿Cómo valido mi Carta Porte mientras tanto?
1Usa el portal general de verificación de CFDI como alternativa — confirma la validez y vigencia del documento correctamente:
verificacfdi.facturaelectronica.sat.gob.mx
verificacfdi.facturaelectronica.sat.gob.mx
2Ingresa el UUID de tu Carta Porte en ese portal — el SAT confirmará directamente que el timbrado es válido y vigente.
3Esta situación se presenta de forma generalizada — no corresponde a un problema particular de tu operación ni de tu integración con SW.
4Opción adicional: si lo consideras conveniente, puedes acompañar el documento físico con la constancia de validación obtenida desde el portal general de verificación del SAT como respaldo complementario.
Puedes confirmar que tu CFDI está correctamente timbrado ingresando el UUID directamente en el portal de verificación del SAT — si aparece como vigente, el documento es válido.
Mayo 2026
“El token debe contener 3 partes” — el token llega vacío o incompleto al timbrar
La autenticación responde con éxito, pero al momento del timbrado el token no llega correctamente al header de la petición — viene vacío, truncado o con caracteres escapados. Es el error más frecuente al integrar con SDK o librería propia.
Frecuencia
Muy frecuente
Flujo correcto de autenticación y timbrado
1. POST /security/authenticate
→ Respuesta:
{
“data”: {
“token”: “T2lYQ0t4L0…”,
“expires_in”: 1630012447,
“token_type”: “Bearer”
},
“status”: “success”
}
2. Extraer el valor de data.token
3. Incluirlo en el header del timbrado:
Authorization: Bearer T2lYQ0t4L0…
Causas más comunes
– El token se extrae del objeto equivocado
(ej. response en lugar de response.data.token)
– El valor se está escapando o codificando
al pasarlo al header
– La versión del SDK está desactualizada
– Se usa token de pruebas en producción
o viceversa
Pasos para resolverlo
1Verifica que estás extrayendo exactamente el campo
data.token de la respuesta de autenticación — no el objeto completo ni otro campo.2Revisa que el token no esté siendo codificado (encode) ni escapado al pasarlo al header. Debe enviarse tal cual como lo devuelve la respuesta.
3El header debe quedar exactamente así:
Authorization: Bearer T2lYQ0t4L0... — con el prefijo Bearer seguido de un espacio y el token sin comillas ni caracteres extra.4Si usas el SDK de SW: verifica que tienes la versión más reciente descargándola desde Librerías SW. Una versión desactualizada puede generar este comportamiento.
5Si el problema persiste o quieres evitar gestionar la expiración del token, considera usar un Token Infinito — no caduca y simplifica la integración.
El Token Infinito es ideal si tu sistema no necesita rotar credenciales — lo generas una vez y lo configuras como constante en tu integración, eliminando por completo los errores de autenticación por expiración.
Mayo 2026
Olvidé mi contraseña o ya no puedo acceder al portal de SW
No puedes iniciar sesión en el portal de SW porque olvidaste tu contraseña o la cambiaste y perdiste el acceso. El proceso de recuperación es directo desde el portal y llega a tu correo registrado.
Frecuencia
Muy frecuente
¿A qué portal entro?
Producción: https://portal.sw.com.mx
Pruebas: https://portal.test.sw.com.mx
Usa el portal que corresponde al ambiente
de tu cuenta.
Pasos para recuperar tu contraseña
1Entra al portal correspondiente a tu ambiente y haz clic en “Recuperar Contraseña” — está justo debajo del botón Ingresar.
2Ingresa el correo electrónico con el que registraste tu cuenta en SW y haz clic en “Enviar”.
3Revisa tu bandeja de entrada — incluyendo la carpeta de spam o correo no deseado. Recibirás un correo con las instrucciones para restablecer tu contraseña.
4Una vez restablecida la contraseña, si la tenías configurada en algún ERP u otro sistema (Odoo, SAP, etc.), recuerda actualizarla también ahí para que el timbrado no se interrumpa.
Si recuperaste la contraseña del portal pero sigues sin poder timbrar desde tu sistema, recuerda que el Bearer Token de la API es independiente — debes regenerarlo también con
POST /security/authenticate usando la nueva contraseña.
Mayo 2026
AU2000 — “El usuario y/o contraseña son inválidos” al autenticarse vía API
Las credenciales parecen correctas pero al autenticarse vía API recibes el error AU2000. Puede deberse a una contraseña incorrecta o desactualizada, o a estar usando un endpoint de autenticación desactualizado.
Frecuencia
Muy frecuente
Mensaje de error
HTTP 400
AU2000 — El usuario y/o contraseña son inválidos,
no se puede autenticar el servicio.
Pasos para resolverlo
1Verifica que tu contraseña sea correcta intentando entrar directamente al portal: Pruebas: portal.test.sw.com.mx · Producción: portal.sw.com.mx. Si no puedes entrar, el problema es la contraseña.
2Si no recuerdas tu contraseña, restablécela desde el portal correspondiente a tu ambiente — haz clic en “Recuperar Contraseña” e ingresa tu correo registrado. Recibirás un enlace para actualizarla.
Pruebas: portal.test.sw.com.mx/recuperar-contrasena
Pruebas: portal.test.sw.com.mx/recuperar-contrasena
3Una vez que puedas entrar al portal, vuelve a intentar la autenticación vía API con la contraseña actualizada.
4Si el error persiste aunque la contraseña sea correcta, revisa que tu sistema o ERP no esté guardando una contraseña anterior — actualízala también en tu integración.
Asegúrate de estar usando la versión actualizada del endpoint de autenticación — debe incluir
/v2/ en la URL:services.test.sw.com.mx/v2/security/authenticate (pruebas)api.sw.com.mx/v2/security/authenticate (producción). El endpoint sin /v2/ es una versión anterior que puede reproducir este error.
Mayo 2026
Cancelé con Motivo 01 pero el CFDI sigue “Vigente” o no llega al SAT
La cancelación con Motivo 01 requiere un paso previo que frecuentemente se omite: el CFDI sustituto debe incluir la relación
TipoRelacion="04" apuntando al UUID del CFDI a cancelar. Sin esa relación, la solicitud se recibe pero no puede ser procesada por el SAT.Frecuencia
Frecuente
El error más frecuente — falta TipoRelacion=”04″
El CFDI sustituto (factura B) DEBE incluir:
<cfdi:CfdiRelacionados TipoRelacion=”04″>
<cfdi:CfdiRelacionado
UUID=”[UUID-del-CFDI-a-cancelar]”/>
</cfdi:CfdiRelacionados>
Sin este nodo la cancelación se recibe pero
NO puede ser autorizada por el SAT.
Pasos para resolverlo — Motivo 01
1Primero timbra el CFDI sustituto (factura B) incluyendo el nodo
CfdiRelacionados con TipoRelacion="04" y el UUID del CFDI original (factura A) que vas a cancelar.2Después solicita la cancelación del CFDI original (factura A) con Motivo 01, incluyendo el UUID de la factura B en el campo
FolioSustitucion.3Verifica el estatus de la cancelación en el portal de verificación del SAT ingresando el UUID de la factura A.
4Para más detalle sobre este flujo y otros escenarios de cancelación, consulta la guía de preguntas frecuentes de cancelación del SAT.
El orden importa: 1) timbra la factura B con relación 04 apuntando a la factura A, 2) cancela la factura A con Motivo 01 incluyendo el folio de la factura B. Invertir el orden hace que la cancelación quede sin efecto aunque se reciba correctamente.
Mayo 2026
Error en los datos del receptor — RFC, código postal fiscal o UsoCFDI
En CFDI 4.0 los datos del receptor son obligatorios y deben coincidir exactamente con el SAT: RFC activo, nombre, código postal fiscal, régimen fiscal y UsoCFDI compatible con el régimen.
Frecuencia
Moderado
Campos obligatorios del receptor en CFDI 4.0
Receptor.Rfc → RFC activo en SAT
Receptor.Nombre → Razón social exacta SAT
Receptor.DomicilioFiscalReceptor → CP fiscal (no el comercial)
Receptor.RegimenFiscalReceptor → Régimen del receptor
Receptor.UsoCFDI → Compatible con su régimen
Pasos para resolverlo
1Valida el RFC de tu receptor con el Validador SAT para RFC — debe estar activo.
2El
DomicilioFiscalReceptor es el Código Postal registrado ante el SAT, no el de la dirección de entrega ni el comercial. Pídelo directamente a tu cliente.3Verifica que el
UsoCFDI sea compatible con el RegimenFiscalReceptor en la matriz de catálogos SAT.4Para público en general: usa RFC
XAXX010101000 (México) o XEXX010101000 (extranjero), con UsoCFDI="S01" y RegimenFiscalReceptor="616".El error más frecuente es usar el Código Postal de la dirección comercial o de entrega. El
DomicilioFiscalReceptor es exclusivamente el que el receptor tiene registrado ante el SAT — son campos distintos. Mira este video para más detalle: TIPS-DEVS | Código de Error CFDI40147 — DomicilioFiscalReceptor.
Mayo 2026
Error 305 en Odoo — Certificado no encontrado en LCO para validar vigencia
Al intentar timbrar desde Odoo aparece el error 305. Las dos causas más frecuentes son: cargar la e.firma (FIEL) en lugar del CSD, o usar un certificado de pruebas con serie no registrada en la LCO del sandbox.
Frecuencia
Frecuente
Mensaje de error
Error 305 — Certificado no encontrado en LCO
para validar vigencia de obligaciones.
Causa 1 — Estás cargando la e.firma (FIEL) en lugar del CSD
La e.firma y el CSD son certificados diferentes:
e.firma (FIEL) → para trámites ante el SAT
→ serie termina en …FIEL o similar
→ NO sirve para timbrar
CSD (Certificado de Sello Digital) → para timbrar CFDI
→ debe estar registrado en el SAT
→ se tramita en el portal del SAT
Causa 2 — CSD de pruebas con serie no registrada en LCO del sandbox
No todos los CSD de pruebas están registrados
en la LCO del ambiente sandbox.
Si usas un certificado de pruebas con serie
no registrada, obtendrás el error 305 aunque
el CSD sea válido.
Pasos para resolverlo
1Verifica qué tipo de certificado tienes cargado en Odoo — puedes consultarlo en el portal de certificados del SAT. Si la serie corresponde a una e.firma, necesitas tramitar un CSD.
2Para producción: tramita tu CSD (Certificado de Sello Digital) directamente en el portal del SAT. Es diferente a la e.firma y es el único válido para timbrar CFDI.
3Para pruebas: descarga los CSD de pruebas vigentes y validados desde el portal SW — usa únicamente los certificados listados ahí, ya que son los que tienen serie registrada en la LCO del sandbox.
Mira este video para más detalle sobre el error 305: TIPS-DEVS | Código de Error 305 — Certificado no encontrado en LCO.
Mayo 2026
¿Cuándo uso ObjetoImp “01”, “02” o “03” en mis conceptos?
En CFDI 4.0 el atributo
ObjetoImp es obligatorio en cada concepto. Indica si el concepto genera impuestos o no, y determina si debes incluir el nodo de impuestos dentro del concepto.Frecuencia
Frecuente
Valores del atributo ObjetoImp
ObjetoImp=”01″ → No es objeto de impuesto
Concepto exento de IVA/IEPS
NO incluir nodo cfdi:Impuestos en el concepto
ObjetoImp=”02″ → Sí es objeto de impuesto
Concepto con IVA o IEPS
SÍ incluir nodo cfdi:Impuestos en el concepto
ObjetoImp=”03″ → Sí objeto, impuesto no desglosado
Uso específico: factura global RESICO
Regla práctica
1Si tu concepto lleva IVA o IEPS → usa
ObjetoImp="02" e incluye el nodo cfdi:Impuestos con los traslados correspondientes dentro del concepto.2Si tu concepto está exento de impuestos → usa
ObjetoImp="01" y no incluyas el nodo cfdi:Impuestos en ese concepto.3Si emites facturas globales RESICO → usa
ObjetoImp="03". El impuesto no se desglosa por concepto.4Revisa los ejemplos que tenemos para ti en el catálogo de ejemplos XML y JSON para ver la estructura correcta del nodo según tu tipo de CFDI.
El error más frecuente es usar
ObjetoImp="02" pero olvidar incluir el nodo cfdi:Impuestos dentro del concepto — o al revés, usar ObjetoImp="01" e incluir igualmente el nodo de impuestos. Ambos generan rechazo.¿No encontraste la solución?
Nuestro equipo de soporte técnico está listo para ayudarte. Crea un ticket y te respondemos en breve.
Sin resultados para esa búsqueda
Intenta con otro término o crea un ticket de soporte.