> ## Documentation Index > Fetch the complete documentation index at: https://developers.ipsofactura.com/llms.txt > Use this file to discover all available pages before exploring further. # Timbrado: defaults y campos obligatorios > Qué valores aplica Ipsofactura cuando omites un campo y qué campos son obligatorios de facto. ## Defaults al timbrar `POST /cfdi/timbrar` completa estos campos cuando no los envías: | Campo | Default | Notas | | ------------------ | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fecha` | Fecha y hora actuales | Si la envías, el SAT acepta hasta **72 horas hacia atrás** y **5 minutos hacia adelante** (tolerancia de reloj). Fuera de ese rango: `400`. | | `lugar_expedicion` | Código postal de la empresa emisora | El registrado en `POST /empresas`. | | `moneda` | `MXN` | Para cualquier otra moneda, `tipo_cambio` es **requerido**. | | `exportacion` | `01` (no aplica) | Si la envías, se timbra **tal cual** —nunca se degrada a `01`— y debe ser una clave de `c_Exportacion` (`01`, `02`, `03`, `04`); cualquier otro valor es `400 VALIDATION_ERROR`. Ver [Exportación](#exportación-pedimento-por-concepto). | | `folio` | Consecutivo siguiente por emisor + serie | Ver [recuperación tras timeout](/recuperacion-timeouts): para reintentos seguros conviene asignar serie y folio propios. | | `serie` | Sin serie | Opcional. | | Versión CFDI | `4.0` | Siempre; no es configurable. | ## Precedencia de los datos del emisor El RFC del emisor **siempre** sale de `rfc_emisor` (raíz del request) y debe corresponder a una empresa registrada en tu cuenta. El objeto `emisor` (nombre y régimen fiscal) es opcional. La regla es: **lo que mandes en el request gana**; lo que omitas se completa con lo registrado en la empresa: * Sin objeto `emisor` → se usan el `nombre_fiscal` y `regimen_fiscal` registrados. * Con `emisor.regimen_fiscal` → ese régimen se usa para este CFDI, aunque difiera del registrado. ## Obligatorios de facto Estos campos aparecen como opcionales en el esquema histórico, pero omitirlos produce un `400` o un rechazo del SAT — trátalos como obligatorios: | Campo | Por qué | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `receptor.regimen_fiscal` | CFDI 4.0 lo exige; debe ser el de la constancia de situación fiscal del receptor. | | `receptor.uso_cfdi` | CFDI 4.0 lo exige, y debe ser aplicable al régimen del receptor. Receptor extranjero (`XEXX010101000`): siempre `S01`. | | `receptor.domicilio_fiscal` | Código postal fiscal del receptor (no el de entrega). | | `conceptos[].objeto_imp` | `01` no objeto de impuesto, `02` sí objeto, `03` sí objeto y no obligado al desglose. | | `forma_pago` y `metodo_pago` | **Requeridos** para `tipo_comprobante` I y E. **Prohibidos** para P (el pago va dentro del complemento). | ## Receptor extranjero Un receptor sin RFC mexicano se timbra con el RFC genérico `XEXX010101000`, `uso_cfdi` `S01` y dos campos opcionales que llevan sus datos fiscales reales al CFDI: | Campo | Nodo del CFDI | Qué lleva | | ---------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------- | | `receptor.residencia_fiscal` | `cfdi:Receptor@ResidenciaFiscal` | País de residencia fiscal: clave del catálogo `c_Pais` del SAT, ISO 3166-1 alpha-3 (`COL`, `USA`, `ESP`, …). | | `receptor.num_reg_id_trib` | `cfdi:Receptor@NumRegIdTrib` | Su número de registro de identidad fiscal —TAX ID, VAT, NIT— tal cual lo emite su país. Máximo 40 caracteres. | ```json Receptor extranjero theme={null} { "rfc_emisor": "EKU9003173C9", "receptor": { "rfc": "XEXX010101000", "nombre": "ACME COLOMBIA SAS", "regimen_fiscal": "616", "domicilio_fiscal": "06000", "uso_cfdi": "S01", "residencia_fiscal": "COL", "num_reg_id_trib": "900123456-7" } } ``` Las tres reglas, validadas antes de llamar al PAC (todas `400 VALIDATION_ERROR`, sin consumir timbre): * `num_reg_id_trib` **requiere** `residencia_fiscal`: un identificador fiscal extranjero no significa nada sin el país que lo emitió. * `residencia_fiscal` sólo aplica a un receptor extranjero, es decir con RFC `XEXX010101000`. Enviarla con un RFC nacional es un error, no un campo que descartemos en silencio. * `residencia_fiscal` debe ser una clave de `c_Pais`. Los dos campos viajan igual por `POST /cfdi/timbrar-xml` (se leen del XML que envías, no se descartan) y un complemento de pago los **hereda** de la factura que liquida, porque el SAT exige que el receptor del CFDI tipo P sea el de la factura relacionada. Al recuperar el CFDI, `GET /cfdi/{id}` los devuelve como `receptor_residencia_fiscal` y `receptor_num_reg_id_trib`. ## Exportación: pedimento por concepto Para una operación de exportación, además de `exportacion` (`02` definitiva, `03` temporal, `04` definitiva con clave distinta a A1), cada concepto importado puede declarar su `pedimento`, que se timbra en `cfdi:InformacionAduanera@NumeroPedimento`. `pedimento` son **21 caracteres exactos** en el formato del SAT `AA␣␣AA␣␣PPPP␣␣NNNNNNN`, con **dos espacios** entre grupos: 2 dígitos del año de validación, 2 de la aduana, 4 de la patente y 7 del consecutivo. Un espacio sencillo es el error más común y responde `400 VALIDATION_ERROR`. ```json Concepto con pedimento theme={null} { "exportacion": "02", "conceptos": [ { "clave_prod_serv": "01010101", "cantidad": 1, "clave_unidad": "H87", "descripcion": "Mercancía de exportación", "valor_unitario": 1000.00, "importe": 1000.00, "objeto_imp": "01", "pedimento": "26 24 3456 7654321" } ] } ``` ## Retenciones a nivel comprobante En el nodo global `impuestos.retenciones[]` el SAT sólo admite dos atributos: el impuesto y el importe. Si envías además `base`, `tipo_factor` o `tasa_o_cuota`, se **aceptan** —no rompemos integraciones existentes— pero el CFDI se timbra únicamente con `impuesto` e `importe`. Esos valores sí se conservan: se usan después para prorratear la retención de cada documento relacionado al emitir un complemento de pago. En las retenciones a nivel **concepto** los cinco campos sí se timbran, porque ahí el SAT los declara. ## Tipos de comprobante soportados `tipo_comprobante` acepta **I** (ingreso), **E** (egreso) y **P** (pago, vía [`POST /cfdi/complemento-pago`](/api-reference/cfdi/complemento-de-pago)). Los tipos T (traslado) y N (nómina) requieren complementos que hoy no generamos, y la API los rechaza con `400 INVALID_TIPO_COMPROBANTE`. Para las ventas al público en general, consulta la guía de [factura global](/factura-global). La referencia completa de cada campo está en [`POST /cfdi/timbrar`](/api-reference/cfdi/timbrar-cfdi), generado directamente del código de la API. ## ¿Ya tienes el CFDI armado en XML? Si tu sistema (ERP, facturador propio) arma el CFDI 4.0 en XML directamente, no necesitas convertirlo a este payload JSON: envíalo sin sellar a `POST /cfdi/timbrar-xml` y Ipsofactura lo sella y timbra igual. Ver [Timbrado por XML](/timbrado-por-xml). ## Recuperar un CFDI después de timbrarlo Para volver a encontrar un CFDI ya timbrado —por tu `serie`/`folio`, por su folio fiscal, o por el `id` que te devolvimos— usa `GET /cfdi/{id}` o los filtros de `GET /cfdi` (`serie`, `folio`, `rfc_emisor`, `folio_fiscal`). Es la base del patrón de recuperación tras un timeout: ver [Recuperación tras timeout](/recuperacion-timeouts).