Qué se comprueba en un archivo de extracto

Estas filas no tienen tantas columnas como la cabecera. El culpable habitual es una coma sin comillas dentro de una descripción («Transferencia a Juan, ahorro»). Los importadores desplazan entonces todas las columnas siguientes o rechazan el archivo. Hay que corregirlo a mano: una reparación automática tendría que adivinar qué coma es real.

Varios importadores dejan de leer en la primera línea en blanco y descartan en silencio todo lo posterior: el clásico «solo se importó la mitad de mis operaciones». Las líneas en blanco pueden eliminarse automáticamente.

Excel añade esta marca al guardar como «CSV UTF-8». Algunos programas de finanzas la leen como parte del nombre de la primera columna («Fecha» en vez de «Fecha») y ya no encuentran la cabecera esperada. Si tu importador se queja de una primera columna desconocida, quítala.

Esto es exactamente lo que YNAB informa como «archivo vacío» y otros programas como «0 operaciones importadas». La exportación de tu banco no contenía filas: normalmente un periodo sin movimientos, o un botón de exportar que solo generó los títulos de columna.

Las exportaciones de Excel europeas separan las columnas con «;». Los importadores que esperan comas (YNAB, muchos formularios de carga) leen toda la fila como una sola columna. El archivo puede reescribirse con comas automáticamente; los campos entrecomillados se conservan correctamente.

Nombres de beneficiario como «AT&T» o «H&M» deben escribirse «AT&T» dentro de un archivo OFX/QFX. Un «&» crudo rompe el análisis SGML/XML justo en ese punto: una de las razones más habituales de que un archivo falle al importar aunque se abra sin problema en un editor.

El archivo empieza con una marca UTF-8 invisible. Muchos analizadores OFX exigen que los primeros caracteres sean «OFXHEADER» y, si no, rechazan el archivo como inválido. Es una causa frecuente del error «archivo no válido» en archivos que se ven perfectamente normales en un editor de texto.

El agregado <OFX> nunca se cierra. Suele significar que la descarga se cortó en el banco o en el navegador. La mayoría de los importadores se limitan a decir «no se puede leer el archivo». La etiqueta de cierre puede añadirse, pero comprueba que la lista de operaciones esté completa.

Las fechas OFX deben escribirse como AAAAMMDD (opcionalmente con hora y zona horaria). Valores como «2026-08-01» o «01/08/2026» hacen que el importador rechace la operación o el archivo entero.

Cada <STMTTRN> debe llevar un FITID único: así saben Quicken, QuickBooks y YNAB si una operación ya se importó. Las operaciones sin él se descartan en silencio o hacen fallar toda la importación. Se pueden generar identificadores estables a partir de la fecha, el importe y el beneficiario.

Un archivo OFX 1.x debe empezar con un bloque de cabecera (OFXHEADER:100, DATA:OFXSGML, VERSION, ENCODING …) antes del cuerpo <OFX>. Sin ella, Quicken, QuickBooks y GnuCash rechazan el archivo. Se puede anteponer una cabecera estándar automáticamente.

Los valores TRNAMT deben ser números simples con el punto como separador decimal (por ejemplo -1234.56). Los separadores de miles, símbolos de moneda o espacios hacen que la operación se omita.

Aparecen nombres con acentos o eñes (é, ü, ñ …) en un archivo cuya cabecera declara ASCII puro. Unos importadores los sustituyen por caracteres extraños y otros abortan. Pide al banco una exportación en UTF-8. No se aplica transliteración automática, deliberadamente, para no alterar los nombres.

Dos operaciones distintas comparten el mismo FITID. Los importadores tratan las entradas con igual FITID como una sola operación y omiten todas menos la primera: el clásico «faltan operaciones después de importar». Los duplicados pueden hacerse únicos con un sufijo numérico.

El archivo se lee bien pero no contiene ningún <STMTTRN>. Los programas lo comunican como «archivo vacío» o «0 operaciones importadas». Los bancos generan archivos vacíos cuando el periodo elegido no tiene movimientos: vuelve a descargar con un rango más amplio.

Los archivos QFX y QBO suelen llevar una etiqueta <INTU.BID> que identifica a un banco autorizado para Web Connect. Sin ella, Quicken puede rechazar el archivo con «no es un archivo Web Connect válido». Esta herramienta no inserta identificadores bancarios: ese valor se lo da Intuit al banco. Si no es posible, importa por CSV.

Es un extracto de cuenta de valores (INVSTMTRS), cuyos movimientos son compras, ventas y traspasos en lugar de apuntes bancarios. El archivo no está vacío. Las comprobaciones de todo el documento —cabecera, escapado, fechas, truncamiento— sí se han hecho; las comprobaciones de identificador por operación aún no se admiten para registros de valores.

Cada operación QIF debe terminar con una línea que contenga solo «^». Los registros sin él se funden con la operación siguiente o desaparecen: el clásico «solo se importó una parte de mis operaciones».

Un archivo QIF debe empezar con una declaración de tipo como «!Type:Bank» o «!Type:CCard». Sin ella, GnuCash y Quicken rechazan el archivo o importan cero operaciones. Se puede anteponer un «!Type:Bank» genérico; cámbialo a !Type:CCard para tarjetas de crédito.

Importes como «1,234.56» confunden a varios importadores, que leen la coma como separador de campo o de decimales. Las comas pueden retirarse automáticamente («1234.56»).

Una marca UTF-8 invisible precede a la primera línea «!». Los importadores QIF antiguos la leen como basura y rechazan la cabecera. Puede eliminarse sin riesgo.

Las fechas QIF se escriben, según el país, como M/D/AA, M/D/AAAA o D/M/AA. Otras formas (ISO 2026-08-01, nombres de mes …) hacen que el importador omita registros en silencio. Como QIF no declara su orden de fecha, reescribirla automáticamente sería adivinar: fija el formato en la ventana de importación.

No se encontró ningún registro en una sección !Type:Bank/CCard/Cash, así que el archivo no contiene nada que importar. Si esperabas datos, el rango de fechas de la exportación estaba probablemente vacío.