Volver al Blog
Configuración Regional
Excel
Separador Decimal
Formatos de Fecha
Calidad de Datos

El Fichero de Liquidación Sumaba 577.574,80 en Múnich y 1.526,95 en Mánchester, Chicago Mudó Media Agosto a Otros Diez Meses, y Nadie Editó Una Sola Celda

16/09/2026
El Fichero de Liquidación Sumaba 577.574,80 en Múnich y 1.526,95 en Mánchester, Chicago Mudó Media Agosto a Otros Diez Meses, y Nadie Editó Una Sola Celda

Resumen Rápido

Puntos clave de este artículo

  • 🌍 El mismo fichero sumaba 577.574,80 en Múnich y 1.526,95 en Mánchester — el 0,26% de la verdad — sin una edición, sin un error y sin un aviso entre ambos, porque un valor escrito como texto solo se convierte en número en la máquina que lo abre
  • 🔻 Un punto de millares alemán es un punto decimal inglés: 3.500 pasa a ser 3.5, 18.200 pasa a ser 18.2, y cinco filas por valor de 31.945,00 se convirtieron en silencio en 31,945 — números perfectamente válidos, perfectamente plausibles y equivocados por un factor de mil
  • 🧊 Doce de veinte importes — 544.134,80, el 94,21% del fichero — llegaron como texto porque 12.480,50 no es un número en en-GB, y SUMA ignora el texto por completo, así que el total que parece un total es aritmética sobre ocho celdas en vez de veinte
  • ⚖️ Tres fórmulas, una columna, tres respuestas: =CONTAR.SI(D2:D21;">10000") devuelve 0 porque se salta el texto, =SUMAPRODUCTO(--(D2:D21>10000)) devuelve 12 porque en Excel cualquier texto es mayor que cualquier número, y la verdad son 7
  • 📅 Diez de veinte fechas intercambiaron día y mes en Chicago y las otras diez no: 03/08/2026 pasó a ser el 8 de marzo, pero 17/08/2026 siguió siendo el 17 de agosto porque ningún calendario tiene un mes decimoséptimo — las fechas ambiguas se mueven en silencio y las imposibles son las únicas seguras
  • 🛡️ La solución es no dejar que ninguna máquina adivine: VALOR.NUMERO recibe los separadores como argumentos, FECHA recibe las partes como números, ISO 8601 no tiene segunda lectura en ningún lugar del mundo, y Cambiar tipo con configuración regional de Power Query es donde una importación decide esto una vez en lugar de por escritorio
Tiempo de lectura: ~25 min

El fichero se llama Settlement_2026_08.csv. Múnich lo exporta el primer día hábil del mes, Mánchester lo contabiliza en el libro mayor del grupo, Chicago lo usa para la conciliación intragrupo. Veinte líneas, 577.574,80 de piezas, y lleva años funcionando así — es decir, lleva años sin que nadie lo compruebe.

MúnichMánchesterChicago
Líneas en el fichero202020
=CONTARA() sobre la columna de importes202020
=CONTAR() sobre la columna de importes2088
=SUMA() de los importes577.574,801.526,951.526,95
Líneas con fecha de agosto de 2026202010
Fecha de factura más antigua02/08/202602/08/20268 de febrero de 2026

Nadie editó una celda. Nadie tiene una versión distinta. Hay un fichero, y estas son las cifras que tres personas leyeron de él la misma mañana.

Un número no se guarda como texto y una fecha no se guarda como fecha. En un libro, un número es un doble binario y una fecha es un recuento serial de días, y ninguno de los dos lleva separador de millares, separador decimal ni orden día-mes: eso es presentación, y se aplica después. Así que un valor que ya es un valor viaja perfectamente. El problema es que un CSV no contiene valores en absoluto. Contiene texto, y el texto se convierte en valor solo en el instante en que algo lo interpreta, y la interpretación es la única parte de Excel que pregunta al sistema operativo en lugar de al fichero.

Qué cubre esto. Todo lo de aquí se comporta igual en Excel 2016, 2019, 2021, 2024, Microsoft 365 y Excel para Mac, con las excepciones que se señalan donde aparecen: VALOR.NUMERO necesita Excel 2013 o posterior, y TEXTOANTES/TEXTODESPUES son solo de 365 y 2024. SUMA, CONTAR, CONTARA, CONTAR.SI, CONTAR.SI.CONJUNTO, SUMAR.SI, SUMAR.SI.CONJUNTO, SUMAPRODUCTO, PROMEDIO, MIN, MAX, VALOR, TEXTO, FECHA, DIA, MES, AÑO, FIN.MES, IZQUIERDA, DERECHA, EXTRAE, LARGO, ESPACIOS, SUSTITUIR, ESNUMERO, ESTEXTO, SI, SI.ERROR, BUSCARX, INDICE/COINCIDIR, FILTRAR, UNICOS, ORDENAR y LET se usan tal como funcionan en todas partes. Una liquidación intragrupo es el ejemplo porque el mismo fichero lo leen tres personas con tres teclados, pero es el mismo trabajo que una tarifa de un proveedor extranjero, una exportación de una gestoría de nóminas, un extracto bancario, un volcado de un instrumento de laboratorio o cualquier hoja que empezó su vida en otro sitio.


1) Un Fichero, Tres Totales

Esta es la primera línea del fichero, tal cual, en bytes:

SET-3101;Bearing housing 60 mm;12.480,50;03/08/2026

En Múnich eso son doce mil cuatrocientos ochenta euros con cincuenta céntimos del tres de agosto. Y es también, letra por letra, lo que reciben Mánchester y Chicago. Los tres discrepan porque cada uno entrega la cadena 12.480,50 a un analizador configurado por Windows, y los tres analizadores estaban configurados por tres configuraciones regionales distintas.

  • Múnich (de-DE): millares ., decimal , → el número 12.480,50.
  • Mánchester (en-GB): millares ,, decimal .12.480,50 no es un número. Excel lo deja como texto.
  • Chicago (en-US): idéntico a Mánchester en números, distinto en fechas.

El fichero no cambió. Cambió la lectura, y la lectura no queda registrada en ninguna parte, y por eso esta clase de error no tiene pista de auditoría: no hay un antes y un después, solo dos personas mirando una cosa y viendo dos.

Un Fichero de Liquidación, Leído en Tres Escritorios

La liquidación de agosto de una filial alemana: veinte líneas, 577.574,80 de gasto intragrupo. La columna C es exactamente lo que contiene el fichero — la convención alemana, que es también la española: punto de millares y coma decimal — y es la única columna que es un hecho sobre el fichero y no sobre una máquina. La columna D es lo que un Excel en-GB de Mánchester pone en la celda cuando le llega ese texto, y la columna E dice si el resultado es un número o una cadena: doce son cadenas, cinco son números mil veces más pequeños, tres están bien. La columna F es la fecha tal como está escrita, DD/MM/AAAA, y la columna G es lo que un Excel en-US de Chicago hace con ella: diez intercambian día y mes sin decir nada, y son exactamente las diez cuyo día es 12 o menor. Todas las cifras del artículo salen de esta tabla.

ABCDEFG
1
Ref
Part
Amount as written in Munich
What Manchester stores
Type in Manchester
Date as written
What Chicago stores
2
SET-3101
Bearing housing 60 mm
12.480,50
12.480,50
Text
03/08/2026
8 March 2026
3
SET-3102
Seal kit, nitrile
845,20
845,20
Text
17/08/2026
17 August 2026
4
SET-3103
Drive belt 8M-1120
3.500
3.5
Number
05/08/2026
8 May 2026
5
SET-3104
Grease cartridge 400 g
940
940
Number
21/08/2026
21 August 2026
6
SET-3105
Gearbox, 2-stage 18:1
27.150,00
27.150,00
Text
09/08/2026
8 September 2026
7
SET-3106
O-ring set, metric
62,75
62,75
Text
28/08/2026
28 August 2026
8
SET-3107
Servo motor, 1500 W
18.200
18.2
Number
11/08/2026
8 November 2026
9
SET-3108
Coupling, jaw type
4.390,90
4.390,90
Text
14/08/2026
14 August 2026
10
SET-3109
Cable gland M20
75
75
Number
02/08/2026
8 February 2026
11
SET-3110
Press frame, welded
156.800,00
156.800,00
Text
25/08/2026
25 August 2026
12
SET-3111
Proximity sensor M12
2.450
2.45
Number
07/08/2026
8 July 2026
13
SET-3112
Hydraulic hose assembly
9.315,45
9.315,45
Text
19/08/2026
19 August 2026
14
SET-3113
Locking collar 45 mm
480
480
Number
12/08/2026
8 December 2026
15
SET-3114
Control cabinet IP55
33.670,25
33.670,25
Text
30/08/2026
30 August 2026
16
SET-3115
Encoder, incremental
1.075
1.075
Number
06/08/2026
8 June 2026
17
SET-3116
Shim pack, assorted
88,60
88,60
Text
23/08/2026
23 August 2026
18
SET-3117
Line conveyor, 12 m
245.900,00
245.900,00
Text
04/08/2026
8 April 2026
19
SET-3118
Pneumatic cylinder 80
6.720
6.72
Number
16/08/2026
16 August 2026
20
SET-3119
Filter element, 10 um
1.390,35
1.390,35
Text
10/08/2026
8 October 2026
21
SET-3120
Safety relay, dual ch.
52.040,80
52.040,80
Text
31/08/2026
31 August 2026

fxLas celdas con fórmulas están resaltadas en verde

Pasa el mouse sobre las celdas con fórmulas para ver la fórmula y resaltar las celdas referenciadas

🎯 Escenario: La pregunta que hay que hacerle a cualquier fichero que llega de fuera de tu edificio no es «¿abre?» — siempre abre. Es «¿quién decidió qué significan estos caracteres?». Si la respuesta es «la máquina que resultó hacer doble clic», entonces el fichero no tiene un significado fijo y el número de tu pantalla es una propiedad de tu escritorio.


2) El Punto Que Divide Entre Mil

Doce de los veinte importes llevan los dos separadores, así que Mánchester los rechaza de plano y los deja como texto. Ese es el fallo ruidoso. El silencioso son los otros cinco.

escrito en Múnich   significa      Mánchester lee
3.500                3.500,00            3.5
18.200              18.200,00           18.2
2.450                2.450,00            2.45
1.075                1.075,00            1.075
6.720                6.720,00            6.72
                  -----------        --------
                    31.945,00          31,945

Cada uno de esos cinco es un número válido. No se marca nada, nada queda alineado a la izquierda, nada lleva triangulito verde. Se sientan en la columna con exactamente el mismo aspecto que las tres filas que sí son correctas, y están equivocados por un factor de mil.

Y las tres que son realmente correctas — 940, 75 y 480, 1.495,00 entre las tres, el 0,26% del fichero — son correctas por la única razón de que resulta que están por debajo de mil y por tanto no llevan separador ninguno. Si los cartuchos de grasa hubieran costado 1.940 en vez de 940, esa fila se habría unido a las otras cinco.

🎯 Escenario: Un importe entero con un único punto a tres dígitos del final es la cadena más peligrosa que existe en datos transfronterizos, porque las dos lecturas son legales y solo una se marca. Cuando recibas una columna de importes y todos los valores sean sospechosamente pequeños y sospechosamente precisos — 3.5, 18.2, 6.72 donde esperabas miles — no estás viendo redondeo. Estás viendo un separador de millares leído como punto decimal.


3) Los Doce Que No Son Números, y la Comprobación Que No Los Ve

Las doce filas restantes — 544.134,80, el 94,21% del fichero — entran como texto, y SUMA no las ignora por cortesía. SUMA no puede verlas en absoluto: los argumentos de texto dentro de un rango los omiten todos los agregados numéricos de Excel, en silencio y por diseño.

=CONTARA($D$2:$D$21)    → 20     todas las celdas tienen algo dentro
=CONTAR($D$2:$D$21)     →  8     ocho de esas cosas son números
=SUMA($D$2:$D$21)       →  1.526,95
=PROMEDIO($D$2:$D$21)   →    190,87     el promedio real es 28.878,74

Que CONTARA y CONTAR difieran en doce es el dato más útil que existe sobre este fichero, y nadie lo mira, porque CONTARA por su cuenta devuelve 20 y 20 es la respuesta correcta a la pregunta que todo el mundo se hace de verdad: ¿han llegado todas las líneas?

Sí han llegado. Llegaron, y después doce de ellas dejaron de ser dinero.

La línea más grande del fichero es SET-3117, un transportador de doce metros a 245.900,00 — el 42,58% de la liquidación él solo. Es texto. SUMA no lo ha visto nunca.

🎯 Escenario: Pon =CONTAR(rango)&" de "&CONTARA(rango) en una celda encima de cada columna numérica importada y déjala ahí para siempre. Cuesta una celda, dice «8 de 20» la mañana en que esto ocurre, y es la única comprobación de este artículo que no requiere saber de qué país venía el fichero.


4) El Texto Es Mayor Que Cualquier Número

La liquidación tiene una regla de aprobación: todo lo que pase de 10.000 necesita una segunda firma. Dos personas escribieron dos comprobaciones para ella, las comprobaciones no coinciden, y ninguna de las dos está rota.

=CONTAR.SI($D$2:$D$21;">10000")          → 0
=SUMAPRODUCTO(--($D$2:$D$21>10000))      → 12
la verdad                                → 7

Las dos fórmulas son implementaciones correctas de dos reglas distintas, y las reglas difieren porque Excel tiene dos formas de decidir si algo es mayor que 10.000.

CONTAR.SI con un criterio de comparación numérica solo considera valores numéricos. El texto no es menor y no es igual: es no elegible, así que las doce filas de texto se omiten, y de los ocho números que quedan el mayor es 940. Cero.

Una comparación directa con > no omite nada, porque Excel define un orden entre tipos: todo número es menor que todo texto, que es también la razón de que una columna mixta se ordene con los números delante. Así que "12.480,50">10000 es VERDADERO, y también lo es "88,60">10000, una fila que de verdad vale 88,60. Doce.

Siete filas superan realmente los 10.000 y valen 546.241,55. Ninguna de las dos comprobaciones las encontró, y la que informó de cero es la que se lee como un certificado de buena salud.

🎯 Escenario: Siempre que dos comprobaciones sobre el mismo rango no coincidan, no elijas la que prefieras: la discrepancia es en sí misma el hallazgo, y casi siempre significa que el rango mezcla números y texto. =SUMAPRODUCTO(--ESTEXTO(rango)) te dice en una celda cuánta mezcla hay.


5) Media Agosto, en Otra Parte

Los importes de Chicago se rompen exactamente igual que los de Mánchester. Las fechas se rompen de otra manera, y peor, porque una fecha equivocada produce otra fecha perfectamente buena.

El fichero escribe las fechas como DD/MM/AAAA. Un Excel en-US lee MM/DD/AAAA. Cuando el día es 12 o menor, las dos lecturas son posibles, Excel se queda con la suya, y no dice nada:

03/08/2026  →  8 de marzo de 2026        el 3 de agosto pasó a ser el 8 de marzo
05/08/2026  →  8 de mayo de 2026
09/08/2026  →  8 de septiembre de 2026
11/08/2026  →  8 de noviembre de 2026
12/08/2026  →  8 de diciembre de 2026

Cuando el día es 13 o superior no hay segunda lectura — ningún calendario tiene un mes decimoséptimo — así que Excel recurre a la única interpretación que funciona y acierta:

17/08/2026  →  17 de agosto de 2026      correcto
25/08/2026  →  25 de agosto de 2026      correcto
31/08/2026  →  31 de agosto de 2026      correcto

Diez de las veinte líneas se mueven. Valen 312.700,85, el 54,14% de la liquidación, y caen en el día 8 de marzo, abril, mayo, junio, julio, septiembre, octubre, noviembre, diciembre y febrero — diez meses distintos, y ninguno es agosto. Las otras diez son perfectas. Una columna en la que todos los valores están mal se detecta en el primer desplazamiento; una en la que la mitad están mal y las veinte son fechas plausibles con el formato correcto, no.

El filtro de cierre de mes de Chicago, =SUMAR.SI.CONJUNTO($D:$D;$F:$F;">="&FECHA(2026;8;1);$F:$F;"<="&FECHA(2026;8;31)), está escrito impecablemente y devuelve una respuesta impecablemente equivocada, porque el defecto está aguas arriba. =MIN($F$2:$F$21) informa de que la factura más antigua de la liquidación es del 8 de febrero de 2026, seis meses antes de que empezara el periodo, y ese es el único síntoma que alguien podría haber notado.

🎯 Escenario: Cuenta tu propia ambigüedad antes de fiarte de una columna de fechas importada: =SUMAPRODUCTO(--(DIA($F$2:$F$21)<=12)) devuelve 10 aquí. No es un recuento de errores: es un recuento de las filas que pueden estar mal sin que nada dé error. Si es cero, la columna es segura sea cual sea la configuración regional. Si es casi toda la columna, no sabes nada de esas fechas hasta que sepas quién las interpretó.


6) Qué Viaja Dentro del Fichero y Qué Se Vuelve a Decidir al Llegar

Este es el modelo entero, y es lo bastante corto como para memorizarlo.

Viaja intacto, en todas partes, siempre:

  • Los números. Guardados como dobles binarios. 12480.5 es 12480.5 en Riad, en Lima y en Oslo.
  • Las fechas y las horas. Guardadas como números de serie: 46.617 es el 3 de agosto de 2026 escriba la máquina 03/08, 08/03 o 2026-08-03.
  • Las fórmulas. El formato de fichero las guarda con nombres de función en inglés y con comas, siempre. SUMIFS y SUMAR.SI.CONJUNTO son una función con dos nombres de pantalla, y los puntos y coma que teclea un compañero alemán no están nunca en el fichero.
  • Los formatos de número. Un código como #,##0.00 se guarda con , y . como marcadores de posición que significan «separador de millares aquí, separador decimal aquí», y cada máquina los dibuja con sus propios caracteres. Por eso la misma celda muestra 12,480.50 en Mánchester y 12.480,50 en Múnich y es el mismo número en las dos.

Se vuelve a decidir al llegar, por la máquina y no por el fichero:

  • Cualquier texto que tenga que convertirse en número o en fecha. Celdas de CSV, texto pegado, teclear, VALOR, FECHANUMERO.
  • Las cadenas de criterio dentro de CONTAR.SI, SUMAR.SI.CONJUNTO y compañía — sección 10.
  • Los códigos de formato dentro de TEXTO() — sección 9.
  • El delimitador con el que se parte un CSV, y con el que se escribe — el separador de listas de Windows, sección 7.

Es decir: un .xlsx es seguro frente a la configuración regional y un .csv no lo es. Todo lo de este artículo ocurre porque una liquidación totalmente calculada, totalmente tecleada y totalmente inequívoca dentro de un libro se aplasta en caracteres al salir y hay que adivinarla de vuelta a valores al entrar.

🎯 Escenario: Si controlas los dos extremos de una entrega recurrente, deja de mandar CSV. Un .xlsx con esas mismas veinte filas se habría abierto idéntico en los tres escritorios, sin ajustes que acordar y sin conversación que tener. Cuando no controlas los dos extremos — y normalmente no los controlas — da por ambigua cada columna de texto hasta que algo de tu propio fichero la vuelva definida.


7) El Punto y Coma No Es Otro Excel

Abre un libro en Múnich y las fórmulas se leen =SUMAR.SI.CONJUNTO(D2:D21;C2:C21;"Bearing"). Esto alarma a la gente, y es lo menos importante de este artículo.

Windows deriva el separador de listas del separador decimal: donde el decimal es una coma, el separador de argumentos pasa a ser un punto y coma, porque una coma no puede hacer los dos trabajos a la vez. Excel muestra y acepta fórmulas con el separador local que sea, y guarda comas en el fichero en cualquier caso. No se convierte nada, no hay nada en riesgo, y un libro que va y viene no acumula daño.

Tres sitios donde sí muerde:

  1. Pegar texto de fórmula. Una fórmula copiada de un correo, de un blog o de un chat es una cadena, y una cadena escrita con comas no se interpretará en una máquina que espera puntos y coma. Esa es toda la razón de la mala fama del separador.
  2. Fórmulas construidas como texto. Todo lo que ensambla una fórmula a partir de cadenas — INDIRECTO, una asignación .Formula de VBA, un generador de código — está escribiendo para una convención. .Formula quiere sintaxis estadounidense; .FormulaLocal quiere la del usuario.
  3. Las constantes matriciales. Donde el decimal es una coma, el separador de columnas dentro de {…} es la barra invertida y el de filas el punto y coma, de modo que {1,2,3} se teclea {1\2\3}. Las constantes pegadas de otro sitio fallan por un motivo que no parece un motivo.

Y una que pilla a todo el mundo: la exportación «CSV (delimitado por comas)» de Excel escribe el separador de listas, no una coma. Guarda esa liquidación en Múnich y obtienes un fichero delimitado por puntos y coma con .csv al final, que es exactamente lo que es la muestra del principio de este artículo.

🎯 Escenario: No muevas nunca una fórmula entre máquinas como texto si puedes moverla como fichero. Si no queda otra — un ticket de soporte, una página de documentación — di en qué convención la escribiste, y cuenta con que quien la lea la tenga que cambiar. Y cuando un fichero «delimitado por comas» resulte estar lleno de puntos y coma, no hay nada corrupto: estás leyendo un fichero escrito por una máquina cuya coma estaba ocupada.


8) Los Nombres de Función Son un Idioma de Pantalla

Excel traduce los nombres de función en la interfaz para unos cuantos idiomas. El libro no se traduce, porque el libro nunca guardó la traducción: guarda SUMIFS y la interfaz pinta SUMAR.SI.CONJUNTO encima.

Dos consecuencias, las dos leves y las dos dignas de saberse:

  • Una fórmula tecleada en el idioma equivocado da #¿NOMBRE?. Teclea =SUMAR.SI.CONJUNTO(...) en un Excel en inglés y no es una función, es un nombre indefinido.
  • Una fórmula pegada como texto se lleva su idioma consigo, que es el mismo problema que el del punto y coma y tiene la misma cura.

En Microsoft 365 el idioma de las fórmulas es un ajuste propio (Archivo → Opciones → Idioma), independiente del idioma de presentación, y esa es la respuesta práctica para quien trabaja en un idioma y lee documentación en otro.

El único caso en que un nombre sí se guarda son las funciones nuevas en un Excel viejo: un fichero que usa BUSCARX abierto en Excel 2016 muestra _xlfn.XLOOKUP y devuelve #¿NOMBRE?. Eso es un problema de versión disfrazado de problema de idioma, y no se arregla cambiando un ajuste.

🎯 Escenario: Si un compañero te reporta #¿NOMBRE? en una fórmula que a ti te funciona, hazle dos preguntas antes de mirar la fórmula: qué versión y qué idioma de fórmulas. Entre las dos explican casi todos los #¿NOMBRE? que no son una errata.


9) TEXTO() Lee Su Código de Formato en la Lengua Local

El formato de número de una celda se guarda en el fichero y es seguro. El código de formato que le pasas a TEXTO() es una cadena dentro de una fórmula, y TEXTO() lo lee en el idioma de la máquina.

=TEXTO($F2;"dd mmm aaaa")

En un Excel en español, d es día, m es mes y a es año, y eso devuelve 03 ago 2026. Ese mismo código en un Excel en inglés no describe lo que crees: allí el año se escribe con y, y "aaaa" no es nada. Y en Múnich, donde los códigos de fecha son T de Tag, M de Monat y J de Jahr — y donde la m minúscula significa minutos — lo que vuelve tampoco es la fecha que pediste. Escribe "TT MMM JJJJ" y funciona allí y se rompe en los otros dos sitios.

La solución es nombrar el idioma dentro del propio código, algo que funciona desde Excel 2013:

=TEXTO($F2;"[$-es-ES]dd mmm aaaa")     → 03 ago 2026 en todas las máquinas
=TEXTO($F2;"[$-en-GB]dd mmm yyyy")     → 03 Aug 2026 en todas las máquinas

La etiqueta de idioma arregla además los nombres de mes y de día, que es la otra mitad del problema: sin ella, "mmmm" en una máquina española devuelve agosto, que es el comportamiento correcto y la salida equivocada si el informe se va a Londres.

🎯 Escenario: Todo TEXTO() cuyo resultado se una a una etiqueta, a un nombre de fichero, a una clave o a un valor de búsqueda debería llevar una etiqueta de idioma explícita. Todo TEXTO() cuyo resultado lo lea una persona en su propia pantalla no debería llevarla: ese lo quieres localizado. La distinción es si la cadena se va a comparar con algo, y las cadenas que se comparan no pueden variar según el escritorio.


10) Las Cadenas de Criterio Se Releen en la Máquina Que Calcula

Esta es la que sobrevive a guardar el fichero como .xlsx, y por eso la que llega más lejos.

=SUMAR.SI.CONJUNTO($D$2:$D$21;$F$2:$F$21;">=01/08/2026";$F$2:$F$21;"<=31/08/2026")

Las fechas de esa fórmula no son fechas. Son caracteres dentro de una cadena de criterio, y Excel los convierte a fechas cuando la fórmula calcula, usando la configuración de la máquina que está calculando. En Mánchester el primer límite es el 1 de agosto. En Chicago es el 8 de enero. La fórmula se guarda una vez y significa dos cosas, y cambia de opinión cuando el fichero cruza un escritorio, no cuando alguien la edita.

Lo mismo vale para los números en criterios. ">1.000" es mil en Múnich y uno coma cero cero cero en el resto del mundo.

Construye el límite en vez de teclearlo:

=SUMAR.SI.CONJUNTO($D$2:$D$21;$F$2:$F$21;">="&FECHA(2026;8;1);$F$2:$F$21;"<="&FIN.MES(FECHA(2026;8;1);0))

FECHA recibe tres números y devuelve un serial. No hay texto, así que no hay nada que releer. Mejor todavía: apunta los criterios a celdas que contengan fechas de verdad y deja que la hoja enseñe sus propios límites:

=SUMAR.SI.CONJUNTO($D$2:$D$21;$F$2:$F$21;">="&$H$1;$F$2:$F$21;"<="&$H$2)

🎯 Escenario: Trata una fecha o un número tecleados entre comillas como un fallo en cuanto lo veas, aunque ahora mismo la respuesta sea correcta. Es la única construcción de este artículo que seguirá a un libro hasta un formato de fichero seguro frente a la configuración regional y cambiará de significado en silencio años después, en una máquina en la que nadie pensó.


11) No Dejes Nunca Que Excel Adivine

Tres herramientas, en orden de cuánto deberías preferirlas.

VALOR.NUMERO (Excel 2013+) recibe los separadores como argumentos, que es exactamente para lo que existe:

=VALOR.NUMERO($C2;",";".")      → 12480,5 a partir de "12.480,50", en cualquier máquina
=VALOR.NUMERO($C2;".";",")      → para la dirección contraria

VALOR no puede hacer esto. VALOR lee la configuración local, lo que la convierte en la función que causó el problema y no en la que lo resuelve.

FECHA a partir de las partes, cuando el texto tiene una forma conocida:

=FECHA(DERECHA($F2;4)*1; EXTRAE($F2;4;2)*1; IZQUIERDA($F2;2)*1)     → un 3 de agosto de 2026 de verdad

Con una trampa que muerde fuerte: esto solo funciona mientras la columna siga siendo texto. Si Excel ya la convirtió al abrir, IZQUIERDA($F2;2) lee los dos primeros dígitos del número de serie — 46 — y obtienes una fecha de 2046 o un error, de una fórmula que ayer estaba bien. Por eso la interpretación tiene que ocurrir en la importación, antes de que Excel tenga una opinión:

  • Obtener datos → Desde texto/CSV te deja fijar el delimitador y el Origen del archivo, y en el editor, Transformar → Tipo de datos → Usando configuración regional… convierte una columna con las convenciones del origen y no con las tuyas. Esta es la respuesta correcta para cualquier cosa recurrente: queda guardada en la consulta, se ejecuta igual en todos los escritorios, y es el único arreglo de este artículo que sobrevive a que la persona que lo montó se vaya.
  • En el antiguo Asistente para importar texto, el mismo trabajo es el botón Avanzadas del paso 3 y el desplegable Formato de los datos → Fecha: DMA.

ISO 8601 (2026-08-03) cuando el que escribe el fichero eres tú. Es el único texto de fecha sin segunda lectura en ninguna parte: no hay configuración regional que ponga el año primero y luego intercambie los otros dos. Si exportas datos que otras personas van a interpretar, exporta las fechas así y los importes con un . a secas y sin separador de millares, y se acabó la discusión.

🎯 Escenario: La regla es la misma para las dos mitades del problema. Si el significado de un valor depende de quién lo mire, fíjalo con algo que reciba la ambigüedad como argumento explícito — VALOR.NUMERO con sus separadores, FECHA con sus tres números, Power Query con su configuración regional — y nunca con una función que lea el ambiente.


12) Cinco Comprobaciones

Pásalas a cualquier columna que haya llegado de fuera del edificio. Las dos primeras cuestan un minuto y habrían cazado todo lo de este artículo.

1. ¿Cuántos de estos son números de verdad?

=CONTAR($D$2:$D$21)&" de "&CONTARA($D$2:$D$21)     → "8 de 20"

Cualquier cosa que no sea n de n significa que parte de la columna es texto, y todos los totales sobre ella ya están mal.

2. ¿Cuántas fechas admiten dos lecturas?

=SUMAPRODUCTO(--(DIA($F$2:$F$21)<=12))             → 10

Un recuento de las filas que se pueden mover sin dar error. Hazla el día que llega el fichero, no el día que falla la conciliación.

3. ¿Coinciden dos comprobaciones del mismo umbral?

=CONTAR.SI($D$2:$D$21;">10000")                    → 0
=SUMAPRODUCTO(--($D$2:$D$21>10000))                → 12

Iguales es sano. Distintas significa tipos mezclados, y la diferencia es más o menos cuánto de la columna es texto.

4. ¿El total del propio fichero coincide con el tuyo?

La única comprobación que caza las filas mil veces más pequeñas, porque esas son números válidos y ninguna propiedad de la celda las delata. Pide al remitente un total de control en el cuerpo del correo — no dentro del fichero — y compara. 577.574,80 frente a 1.526,95 no es una diferencia sutil.

5. ¿Hay algo sospechosamente preciso?

=SUMAPRODUCTO(--ESNUMERO($D$2:$D$21);--(REDONDEAR($D$2:$D$21;2)<>$D$2:$D$21))     → 1

Una columna de importes debería tener como mucho dos decimales. 1.075 tiene tres, y tres decimales en una columna de dinero son un separador de millares que alguien se comió. Un solo acierto basta para desconfiar de la columna.


13) Doce Trampas

  1. Un CSV contiene texto, no valores. Cada número y cada fecha que hay dentro los vuelve a decidir la máquina que lo abre, y la decisión no queda registrada en ninguna parte.
  2. Un punto de millares pasa a ser un punto decimal. 3.500 leído en en-GB es 3,5: un número válido, sin marcar, plausible, y equivocado por un factor de mil.
  3. Un número con los dos separadores pasa a ser texto. 12.480,50 en en-GB es una cadena, y SUMA, PROMEDIO, MIN y MAX la omiten en silencio.
  4. CONTARA no detecta nada de esto — las celdas están todas llenas. Solo CONTAR al lado te dice algo.
  5. En Excel, todo valor de texto es mayor que todo número. CONTAR.SI(">10000") omite el texto y SUMAPRODUCTO(--(rango>10000)) lo cuenta como acierto, así que el mismo umbral da dos respuestas.
  6. Las fechas con día 12 o menor se intercambian en silencio; las de día 13 o mayor nunca. Una columna de fechas medio rota es mucho más difícil de ver que una rota del todo.
  7. .xlsx es seguro frente a la configuración regional; .csv no. Números, fechas, fórmulas y códigos de formato viajan intactos dentro de un libro.
  8. La exportación «CSV (delimitado por comas)» de Excel escribe el separador de listas de Windows, así que una exportación por comas desde una máquina de coma decimal va delimitada por puntos y coma.
  9. Las cadenas de criterio se interpretan en tiempo de cálculo en la máquina local. ">=01/08/2026" significa dos días distintos en dos países, y esta sobrevive a guardar como .xlsx.
  10. TEXTO() lee su código de formato en la lengua local. Etiquétalo — "[$-es-ES]dd mmm aaaa" — siempre que el resultado se vaya a comparar, unir o archivar en lugar de simplemente leer.
  11. VALOR y FECHANUMERO usan la configuración local; VALOR.NUMERO y FECHA no. Prefiere las dos que reciben la ambigüedad como argumento.
  12. Siguen existiendo dos sistemas de fechas. Los libros creados en versiones antiguas de Excel para Mac cuentan desde 1904 y no desde 1900, y copiar fechas entre un libro de 1904 y uno de 1900 las desplaza 1.462 días — cuatro años y un día — sin error ninguno.

Nada de esta historia es un error. El fichero de Múnich es alemán correcto. El Excel de Mánchester está correctamente configurado para Mánchester. La fórmula de cierre de mes de Chicago es de manual. El ERP exportó las convenciones del país en el que funciona, que es lo único sensato que podía hacer.

Lo que lo vuelve caro es que el coste de la discrepancia lo paga el extremo lejano, alguien que no puede verla. Cualquier otro tipo de dato roto se anuncia: una columna que falta, falta; un fichero corrupto no abre; una fórmula mal escrita devuelve #¡VALOR! en color. Un desajuste de configuración regional devuelve un número. Devuelve un número con la forma correcta, en la columna correcta, dentro de un fichero que abrió limpiamente, y la única prueba de que ha pasado algo es que alguien a mil kilómetros está mirando otro distinto.

Así que la disciplina es estrecha y no va de ajustes. Nadie debería reconfigurar Windows para que un libro funcione; los ajustes son correctos para quien los usa. La disciplina es que allí donde una cadena tenga que convertirse en valor, algo de tu fichero — los dos argumentos de VALOR.NUMERO, los tres números de FECHA, una etiqueta de idioma en un código de formato, un paso de consulta que nombre las convenciones del origen — tiene que decir qué lectura se pretende. Dilo una vez, en la importación, y el fichero significa lo mismo en todos los escritorios en los que aterrice. Déjalo sin decir y el fichero significa lo que signifique el escritorio, que es otra forma de decir que no significa nada.

Comparte este artículo:
Volver al Blog