A menos que se estipule explícitamente, tal y como es la tendencia actual, se factura sobre el recuento final (o sea, de la traducción o corrección).

Algunas empresas y traductores cuentan por líneas, caracteres o páginas. Pero creemos que estas opciones presentan también algunos problemas de arbitrariedad, que requieren una convención adicional:

• Líneas: ¿cuántas palabras o caracteres o espacios por línea?
• Páginas: ¿cuántas palabras, líneas, caracteres por página? Esta concepción mecanográfica aún es más incoherente con los procesadores de texto actuales.
• Caracteres: ¿incluyen espacios o no?, ¿cómo los interpretamos en formatos especiales?, ¿todos los sistemas operativos y conjuntos de ofimática los cuentan igual? Se aproxima mucho al sistema ideal pero, además de las observaciones anteriores, también obliga a una doble operación aritmética y mental si tenemos que establecer tarifas en euros por 100 o por 1.000 caracteres/espacios.
• Palabras: No deja de ser arbitrario, hay que admitirlo, pero requiere "menos" convenciones o dobles operaciones. También es, tal vez, el sistema que se está generalizando más (aunque no de forma absoluta) dentro del sector. Por otro lado, en un entorno multiformato (HTML, software, etc. con muchas etiquetas y códigos) es más fácil discernir lo que es texto a traducir (en palabras) y lo que es código (caracteres arbitrarios).

Word: Se sabe que Word se deja muchos elementos sin contar, especialmente cuadros de texto. Haga la prueba.

Tampoco cuenta texto editable en objetos insertados en el documento (imágenes con texto editable, archivos Word, Excel o PowerPoint insertados en el documento, etc.), y hay que contarlo aparte.

Word tampoco gestiona de manera correcta y transparente el funcionamiento del conjunto de caracteres delimitadores para cada lengua (punto, coma, números, direcciones electrónicas, etc.).