Configura tu facturación · Documentación de Winal

Winal timbra CFDI 4.0 en tu nombre: cada comprobante lleva tu RFC, tu razón social y tu sello. Por eso, antes del primer CFDI hay tres cosas que son tuyas y que ningún proveedor puede poner por ti — tu perfil fiscal, tu CSD y tu cuenta con un PAC. Esta página explica qué es cada una, dónde se captura y cuál es la regla del nombre fiscal que, si la ignoras, hace que el SAT rechace todas tus facturas. Cuando esté listo, la emisión está en Facturación CFDI.

¿Facturas a nombre de tus clientes, cada uno con su propio RFC?

Todo lo de esta página aplica igual por cada cliente, capturado en su cuenta —nunca en la tuya—, y con dos requisitos previos propios de ese flujo (segundo factor y direcciones declaradas) que aquí no se repiten. Ver Da de alta a tus clientes para el recorrido completo, y Cuentas administradas para el modelo y la API.

Las tres piezas

Pieza	Qué es	Dónde se captura hoy
Perfil fiscal	RFC del emisor, razón social, régimen fiscal (c_RegimenFiscal), CP del domicilio fiscal —que es el `LugarExpedicion` del CFDI— y, si quieres, una serie por defecto.	Tú, en Facturación de tu tablero (https://winal.com.mx/app/).
CSD (Certificado de Sello Digital)	El par `.cer` + `.key` con su contraseña, con el que se firma cada comprobante. Lo tramitas tú ante el SAT. Detalle abajo.	Depende de tu PAC: en tu cuenta de Facturama, o cargado en Winal si timbras con Finkok. Ver la tabla.
Cuenta con un PAC (normalmente no es cosa tuya)	El Proveedor Autorizado de Certificación que estampa el timbre fiscal. Hoy: Finkok o Facturama. La pone Winal: somos distribuidores, así que no tienes que contratar nada ni conseguir credenciales de nadie — una farmacia de mostrador no las tiene ni tiene por qué tenerlas.	Nada que hacer. Solo si ya traes contrato propio con un PAC puedes cargar tu usuario y contraseña en Facturación de tu tablero (opcional, y entonces las tuyas ganan). Se guardan cifrados y no se vuelven a mostrar.

Mientras falten, la API te lo dice con un error, no con un misterio

Sin perfil fiscal, todo POST de facturación responde invoice.fiscal_profile_missing; con perfil pero sin credenciales del PAC, invoice.pac_credentials_missing (o invoice.pac_credentials_incomplete si quedaron a medias). Son configuración de tu cuenta, no bugs de tu código: puedes integrar todo lo demás de Winal sin haber tocado el SAT.

Tu CSD: el sello con el que se firma cada factura

El CFDI se emite a nombre de quien vende, con su RFC — así que se firma con su Certificado de Sello Digital. Es el equivalente fiscal de una firma autógrafa: quien tiene ese material puede facturar como tú. Son tres cosas, y las tres las entrega el SAT:

Archivo	Qué es
`.cer`	El certificado público, un X.509 en formato DER (binario, no PEM). De ahí salen el `NoCertificado` (20 dígitos) y el `Certificado` del comprobante.
`.key`	La llave privada, en PKCS#8 cifrada (también DER). Con ella se calcula el `Sello` del CFDI.
contraseña	La que elegiste al generar el CSD. No es la contraseña de tu e.firma ni la de tu cuenta del PAC.

Se tramita gratis y en línea en el portal del SAT (CertiSAT Web), con tu e.firma. Un CSD no es la e.firma: la e.firma te identifica ante el SAT, el CSD sirve exclusivamente para sellar comprobantes. Los CSD del SAT duran cuatro años; cuando el tuyo caduque hay que tramitar otro.

CSD, e.firma y solicitudes: cuál es cuál

Es la confusión de esta pantalla, y no es culpa de nadie: el SAT entrega los dos certificados en el mismo formato, con nombres de archivo parecidos y a menudo en la misma carpeta. Con el vocabulario que vas a ver en pantalla:

Se llama	Qué es y para qué sirve	De dónde sale	¿Se sube a Winal?
CSD Certificado de Sello Digital	Sirve exclusivamente para sellar comprobantes fiscales. Es lo que convierte una venta en un CFDI a tu nombre.	CertiSAT Web → certificados de sello digital. Gratis, en línea, y te identificas ahí con tu e.firma. Sale un `.cer` y, de la aplicación Certifica, un `.key` con la contraseña que tú elegiste.	Sí. Los tres: `.cer`, `.key` y su contraseña.
e.firma antes FIEL	Te identifica ante el SAT para hacer trámites (incluido tramitar tu CSD). No sirve para facturar: el SAT rechaza cualquier comprobante sellado con ella.	De una cita presencial en el SAT. También es un `.cer` + `.key`, con otra contraseña.	No. Winal la rechaza al guardar: `invoice.csd_is_efirma`.
`.req` / `.ren` solicitudes	Son peticiones, no certificados: lo que se envía al SAT para que te emita (o te renueve) uno. Un `.ren` es una solicitud de renovación de la e.firma.	Las genera la aplicación Certifica en tu computadora, junto al `.key`.	No. Winal las rechaza: `invoice.csd_is_certificate_request`.

Cómo distinguirlos si ya no sabes cuál es cuál

Los dos certificados son X.509 en DER, con llave RSA, número de serie de 20 dígitos y tu RFC dentro, así que mirarlos no basta. Lo que los separa es el uso de llave (KeyUsage) que declara el certificado: el CSD trae solo firma y no repudio, y la e.firma añade además usos de cifrado (dataEncipherment, keyAgreement). Eso es exactamente lo que Winal comprueba al guardar, así que no tienes que averiguarlo tú: si subes la que no es, el error te lo dice con nombre y apellido en vez de dejarte descubrirlo semanas después, con el PAC rechazando la factura de un cliente real. Una pista sin abrir nada: si en la carpeta hay un .req o un .ren, estás mirando el paquete de tu e.firma.

El CSD es por RFC

Cada contribuyente sella con el suyo. El CSD de una farmacia no puede facturar las ventas de otra, aunque sean del mismo dueño o del mismo grupo: el CFDI se emitiría a nombre del titular del certificado, no del que vendió. Winal lo comprueba antes de firmar —compara el RFC que declara el propio certificado con el del emisor— y si no coinciden no emite nada (invoice.csd_rfc_mismatch). Si administras varios RFC, cada uno necesita su cuenta con su propio CSD.

Qué hace Winal con él

Lo cifra en reposo. Vive junto a las credenciales de tu PAC, con envelope encryption: una llave AES-256-GCM aleatoria por registro, envuelta a su vez por la llave maestra de la plataforma.
Nunca lo devuelve. Ninguna respuesta de la API, ningún log y ninguna pantalla del tablero muestran el material del CSD: el perfil fiscal solo reporta si hay credenciales configuradas, jamás cuáles.
Nunca sella con el certificado de otro. Antes de firmar, se compara el RFC que declara el propio certificado con el RFC del emisor de la factura; si no coinciden, el comprobante no se emite: invoice.csd_rfc_mismatch. Es la garantía que hace que una plataforma multi-comercio no pueda atribuirle a un contribuyente la factura de otro.
Verifica su propio sello. Después de firmar, el sello se valida contra la llave pública del certificado antes de mandar nada al PAC (invoice.cfdi_seal_failed): se prefiere no emitir a emitir un comprobante mal sellado.

Los errores del CSD, y qué significan

Todos llegan antes de gastar un timbre: se validan al cargar el material, no en el servidor del PAC.

code	Qué pasó
`invoice.csd_missing`	Tu PAC recibe el comprobante ya sellado por Winal, pero tu cuenta no tiene guardado el CSD.
`invoice.csd_certificate_invalid`	El `.cer` no se lee como CSD del SAT: no es el DER original, no trae llave RSA, o su número de serie no son los 20 dígitos del Anexo 20.
`invoice.csd_is_efirma`	Lo que subiste es tu e.firma (antes FIEL), no tu CSD. Con la e.firma no se puede facturar; el mensaje te dice dónde sacar el CSD.
`invoice.csd_is_certificate_request`	Lo que subiste es una solicitud (`.req` / `.ren` de Certifica), que es lo que se envía al SAT, no el certificado que el SAT devuelve.
`invoice.csd_key_invalid`	El `.key` no abre: archivo equivocado o contraseña incorrecta.
`invoice.csd_key_mismatch`	El `.key` no corresponde al `.cer`: son de CSD distintos. El error típico de quien administra varios.
`invoice.csd_rfc_missing`	El certificado no declara el RFC de su titular, así que no es un CSD emitido por el SAT.
`invoice.csd_rfc_mismatch`	El CSD es de un RFC distinto del emisor de la factura.
`invoice.csd_not_valid_at_date`	El CSD no está vigente en la fecha del comprobante; el mensaje trae su rango de vigencia.

Elige tu PAC

El PAC es quien estampa el timbre fiscal ante el SAT. La cuenta es tuya, los timbres los pagas tú, y el PAC es un dato de tu comercio — igual que tu RFC o tu serie —, no una decisión de la plataforma. Hoy hay dos, y la diferencia no es de marca sino de quién arma y sella el XML:

Clave	Quién arma y sella el CFDI	Dónde vive tu CSD	Qué comprobantes puedes emitir hoy
`finkok`	Winal: construye el XML del Anexo 20, calcula la cadena original y lo firma con tu CSD. Finkok es PAC autorizado directo por el SAT y solo le añade el `TimbreFiscalDigital`.	En Winal, cifrado (ver arriba).	CFDI de ingreso (PUE, PPD y la factura GLOBAL), cancelación y descarga de XML/PDF. Solo MXN. Ver los límites de hoy.
`facturama`	Facturama: recibe los datos del comprobante y él lo arma y lo sella.	En tu cuenta de Facturama: el emisor es el dueño de la cuenta y el proveedor administra su CSD. Los datos de tu perfil fiscal en Winal deben coincidir con los de esa cuenta.	Ingreso (incluida la factura GLOBAL), complemento de pagos (REP), nota de crédito, nómina y retenciones.

El PAC de tu cuenta aparece en el campo pac del perfil fiscal, y cada CFDI guarda con cuál se timbró (pac de la factura es inmutable: registra un hecho). Puedes cambiar de PAC —renegocias precio, cambian sus términos— sin que eso toque los comprobantes ya emitidos.

Ambiente: sandbox y producción no se mezclan

Tu perfil fiscal tiene un ambiente (sandbox o produccion) y cada uno guarda sus propias credenciales del PAC. Antes de timbrar, Winal cruza ese ambiente con el de la operación y, si no coinciden, responde invoice.livemode_mismatch sin emitir nada. De dónde sale "el ambiente de la operación" depende de la ruta:

Ruta	Contra qué se cruza
`POST /v1/invoices` `POST /v1/invoices/{id}/payments`	El `livemode` del cobro: un cobro de prueba nunca timbra un CFDI fiscalmente real.
`POST /v1/invoices/pue` `POST /v1/invoices/ppd` `POST /v1/invoices/global`	El `livemode` de la llave (`sk_test_`/`sk_live_`): ninguna de las tres tiene cobro de por medio, así que es la única señal de ambiente que existe.
`POST /v1/invoices/{id}/retry` `POST /v1/invoices/{id}/cancel` `POST .../credit-notes/{id}/cancel`	Lo de arriba, y además el ambiente en que ESE comprobante se timbró — un dato de su propia fila que nunca cambia, ni el día que tu cuenta pasa a producción. Un CFDI nacido en pruebas se reintenta y se cancela SIEMPRE con `sk_test_` y el perfil en `sandbox`.

Por eso, mientras pruebes, deja el perfil en sandbox: es lo que gobierna a las cuatro rutas de EMISIÓN. Los dos sentidos los mueve el dueño desde el tablero, con una condición para subir:

A produccion: solo cuando tu cuenta ya tiene la activación de producción aprobada (esa aprobación es la revisión humana, y es lo que faltaba). Antes de eso recibes production.not_enabled.
De vuelta a sandbox: cuando quieras, sin condiciones.

Al encender producción, reenvía tu CSD en el mismo guardado

El material de timbrado se guarda por ambiente: el CSD que subiste en pruebas no está en el sobre de producción. Manda csd_cer, csd_key y csd_key_password junto con ambiente: "produccion". Si no, el cambio se rechaza con invoice.produccion_not_ready — a propósito, para que no acabes con un perfil "productivo" que falla en cada CFDI real.

¿Te quedaron comprobantes de PRUEBA en error de cuando integrabas? No hay nada que cerrar: nunca tuvieron valor fiscal ni te obligan ante el SAT, así que no hace falta cancelarlos ni reintentarlos. Factura la venta real como un comprobante nuevo — de hecho, ya no podrías reintentar el de prueba con tu llave de producción aunque quisieras (ver la fila de retry/cancel arriba).

La regla que le rompe la facturación a casi todos

El Nombre del emisor debe coincidir con el que el SAT tiene registrado para ese RFC, y ese registro NO incluye el régimen de capital. Va en mayúsculas, sin comas y sin el SA DE CV, S DE RL DE CV, AC… del final. Si no, el SAT rechaza el comprobante con CFDI40138 (y con CFDI40147 cuando el problema es el nombre del receptor).

Esto no es teoría: nos pasó timbrando de verdad

La primera versión del sellador tomaba el nombre del emisor del propio certificado —lo que parece lo más fiel que se puede hacer— y el PAC devolvió CFDI40138. El certificado de prueba del SAT dice ESCUELA WILSON ESQUIVEL S DE CV; el SAT espera ESCUELA WILSON ESQUIVEL. Te lo contamos para que no lo descubras como lo descubrimos nosotros: con un comprobante rechazado y, en tu caso, un cliente enfrente esperando su factura.

Escríbelo así	No así	Por qué
`FARMACIA DEL CENTRO`	`FARMACIA DEL CENTRO, S.A. DE C.V.`	Sobra el régimen de capital y sobra la coma.
`ESCUELA WILSON ESQUIVEL`	`ESCUELA WILSON ESQUIVEL S DE CV`	El caso real de arriba: el certificado lo trae, el registro del SAT no.
`DISTRIBUIDORA LOS PINOS`	`Distribuidora Los Pinos S de RL de CV`	Mayúsculas, y sin el régimen de capital.

Las formas que hay que quitar del final son todas las del catálogo de regímenes de capital, con o sin puntos (S.A. DE C.V. y SA DE CV son la misma):

régimen de capital · va FUERA del nombre

SA · SA DE CV · S DE CV · SAPI · SAPI DE CV · SAS · SAS DE CV
S DE RL · S DE RL DE CV · S DE RL DE CV MI · SC DE RL · SC DE RL DE CV
SPR DE RL · SPR DE RL DE CV · SOFOM · SOFOM ENR · SA DE CV SOFOM ENR · SAPI DE CV SOFOM ENR
SNC · SCP · SCL · SCS · S EN C · S EN CS · S EN NC · S EN C POR A
SC · AC · AR · IAP · ABP

Si eres persona física no hay régimen de capital que quitar: va tu nombre tal como aparece en tu Constancia de Situación Fiscal.

Winal no te lo recorta en silencio, y es a propósito

Podríamos borrar el SA DE CV por ti, pero entonces el nombre que aparece en tu comprobante fiscal ya no sería el que tú revisaste sino uno que inventamos nosotros — y el día que una razón social legítima terminara pareciéndose a un régimen de capital, te habríamos mutilado la factura sin avisar. Winal no adivina ni reescribe datos fiscales del comercio. Captúralo bien una vez, en tu perfil fiscal, y se acabó.

Lo que sí hace Winal es avisarte al guardar: si la razón social termina en un régimen de capital, el perfil se rechaza con invoice.razon_social_con_regimen_capital y el mensaje trae el sufijo detectado y el nombre ya corregido, listo para copiar. Te enteras al capturar —cuando puedes arreglarlo con calma— y no en tu primera venta, con un cliente esperando y un CFDI40138 que no explica nada. Si tu perfil se guardó antes de que esta validación existiera, sigue funcionando igual que siempre y verás el aviso bajo el campo en Tablero → Facturación.

La regla hermana: el receptor "público en general"

Del otro lado del comprobante hay una regla que ya mordió a este producto DOS veces (seis ejemplos de esta misma documentación traían la combinación equivocada, y luego el propio Winal la traía mal en la factura global que arma solo — ver el aviso de abajo). Con el RFC genérico nacional XAXX010101000, el SAT exige las tres juntas:

Campo	Valor obligatorio
`nombre`	`PUBLICO EN GENERAL` — sin acento en la "U", aunque el español correcto lo lleva (Winal compara su propia coherencia sin acentos ni mayúsculas, así que `Publico en general` también pasa esa validación — pero el PAC/SAT no es tan permisivo, ver el aviso de abajo)
`regimen_fiscal`	`616` — Sin obligaciones fiscales
`uso_cfdi`	`S01` — Sin efectos fiscales

Winal valida esa coherencia antes de mandar nada al PAC y responde invoice.receptor_incoherente diciéndote cuál de las tres falló: el rechazo te llega en milisegundos y gratis, en vez de como un error opaco del timbrado con el folio ya consumido. Con el genérico de extranjero (XEXX010101000) aplican el régimen y el uso, pero el nombre es el real de tu cliente. Con un RFC de verdad la regla no aplica: va el nombre de tu cliente y el uso_cfdi que él te pida.

El acento que sí importa: el catálogo del SAT no lo lleva

La factura global la arma Winal internamente — tú no mandas nombre en POST /v1/invoices/global — y aun así llegó a producción con PÚBLICO EN GENERAL (con acento, la ortografía correcta del español). El SAT lo rechazó con CFDI40130 ("el Nombre del receptor es diferente a PUBLICO EN GENERAL"): su catálogo no está escrito en español correcto, y compara byte a byte. La validación propia de Winal (la de la tabla de arriba) compara sin acentos a propósito, para no ser pedante con cómo tecleas el nombre — así que esa validación nunca iba a atrapar este error; solo el PAC real lo hizo. Se confirmó timbrando la MISMA factura contra Finkok dos veces, cambiando solo el acento: con acento, rechazo; sin acento, timbrada. Si alguna vez construyes este receptor a mano, usa el literal exacto de esta tabla — sin acento.

Desde esta ronda: el genérico nacional ya no cabe en un CFDI suelto (CFDI40130)

El SAT no admite un CFDI de ingreso individual con el RFC genérico nacional XAXX010101000 — ni siquiera con la tercia de arriba completa. Esas ventas se acumulan en la factura global del período (POST /v1/invoices/global): POST /v1/invoices, POST /v1/invoices/pue y POST /v1/invoices/ppd ya no lo aceptan en absoluto — responden 400 invoice.global_required_for_publico_en_general antes de mirar el resto del receptor, así que la tercia de arriba ni siquiera se llega a revisar cuando el RFC es este genérico. El genérico de extranjero (XEXX010101000) no cae en esta regla: sigue aplicando solo la tercia de arriba.

El cuarto requisito (CFDI40149) ya no es algo que puedas equivocar

Para el genérico nacional, el SAT exige además que el cp del receptor sea el mismo de tu lugar de expedición. Antes era un rechazo frecuente en mostrador —el punto de venta suele traer un CP fijo de "público en general" propio—, pero como el único lugar donde el genérico nacional sigue existiendo es la factura global, y ahí tú no mandas el receptor (Winal lo arma con el CP de tu perfil fiscal), este cruce ya no puede fallar por tu parte: es correcto por construcción, con cualquiera de los dos PAC.

Dónde se captura cada cosa, hoy

La configuración fiscal es autoservicio en casi todo. Lo que todavía no lo es, lo decimos sin adornos para que no lo busques en una pantalla que no existe:

Dato	Quién lo aplica	Cómo
RFC, razón social, régimen fiscal, CP, serie	tú	Tablero → Facturación. Rol `owner` u `operador`; sobre un perfil ya productivo, solo el dueño.
Usuario y contraseña de tu PAC	tú	Misma pantalla. Se guardan cifrados; déjalos en blanco para no cambiarlos.
Volver de `produccion` a `sandbox`	tú	Misma pantalla. Encender producción, en cambio, lo habilita Winal.
Elegir un PAC distinto del que trae tu cuenta	Winal	Escríbenos a hola@winal.com.mx: hoy el formulario del tablero no lo ofrece.
Cargar el material de tu CSD (`.cer`, `.key`, contraseña)	Winal	Igual: nos lo haces llegar por un canal seguro y queda cifrado en tu cuenta. Solo aplica si timbras con `finkok`; con `facturama` el CSD lo cargas tú en tu cuenta del PAC.

Las rutas de plataforma que aplican esos dos últimos cambios (/admin/*) no están expuestas a internet: se operan desde dentro. Ver Autenticación y seguridad.

Antes de tu primer CFDI

Tu CSD vigente, tramitado en el portal del SAT (no la e.firma).
La cuenta con el PAC — ya la pone Winal; solo la cargas tú si traes contrato propio.
Tu perfil fiscal capturado — con la razón social sin régimen de capital.
La llave correcta: sk_test_ con perfil en sandbox, sk_live_ con perfil en produccion.
Y ya: tu primera factura global del período si nadie te pidió comprobante, o una venta con el RFC de tu cliente si sí.

Lo que no hace falta: un proveedor de cobro. Si vendes de mostrador y cobras en efectivo, facturar es una capacidad completa por sí sola — con eso solicitas la activación de producción y emites tus CFDI reales, sin conectar ningún conector de pago ni configurar ruteo. Ver Tu tablero → El camino a producción.

Siguiente paso

Facturación CFDI — los dos caminos para emitir: sobre un cobro de Winal, o sobre una venta que cobraste tú.
Tu tablero — qué hay en cada sección y quién puede escribir.
Errores — la tabla completa de códigos de facturación con su causa y su remedio.