Qué campos del ACORD 80 se rompen
antes de que la tarificación los vea

El procesamiento directo significa que la solicitud se lee, se verifica y se enruta hacia la tarificación sin que una persona tenga que teclear dos veces un campo. En este formulario, la mayoría de los varios cientos de casillas son administrativas. Los campos del ACORD 80 que deciden el resultado se encuentran en tres lugares: el bloque de construcción, el bloque de protección y el bloque de historial de siniestros. Cada uno falla por una razón distinta, y ninguno de ellos anuncia el fallo.

Quienes lo sufren no son los que rellenan el formulario delante del solicitante. Son el CSR que lo vuelve a teclear en el portal de la aseguradora, el responsable de operaciones que cuenta las devoluciones y el suscriptor que decide si una clase de protección en blanco significa algo. El personal de la agencia describe el dilema con sus propias palabras: «Si no eres extremadamente cuidadoso al introducir los datos, te rechazan o te cotizan mal y la aseguradora culpará al agente», escribe uno, y otro señala que el AMS «no tiene la mayor parte del perfil de riesgo / datos de suscripción al principio, cuando estoy redactando negocio nuevo» (r/InsuranceAgent).

La edición del pie de página determina cómo debe leerse cada una de las demás páginas

La línea de edición del pie de página, no el número de página, es lo que hace legible un ACORD 80, porque la misma sección se encuentra en un lugar distinto en cada edición y versión estatal. La edición 2026/03 sustituyó al formulario base 2016/11: siete páginas en lugar de seis, «Agency» pasó a llamarse «Producer», se añadió una firma de cosolicitante y se reestructuraron las declaraciones estatales de fraude (ACORD forms notification, May 2026). Un archivo de 2024 es un documento distinto del que se imprime este mes, no solo un pie de página diferente.

Las versiones estatales añaden más que un nuevo encabezado de página. La versión de California, ACORD 80 CA (2026/01), añadió una sección de Mitigación de Incendios Forestales de California en la página 5 con cinco preguntas a nivel comunitario que abarcan la inclusión en la lista de Comunidades de Reducción del Riesgo de Incendios según el Public Resources Code 4290.1, el estatus de Firewise USA, los materiales no combustibles en un radio de cinco pies, la eliminación de estructuras combustibles en un radio de 30 pies y el espacio defendible según PRC 4291. El formulario pasó de cinco a seis páginas para albergarla (ACORD forms notification, December 2025). Misisipi y Arkansas recibieron nuevas versiones en febrero de 2026 específicamente para capturar la certificación IBHS FORTIFIED y los datos de mitigación de viento, de modo que las aseguradoras puedan aplicar los descuentos estatutarios en las primas (ACORD forms notification, January 2026). Ninguno de esos campos existe en absoluto en el formulario base 2016/11.

Hay una segunda fuente de deriva de ediciones dentro de la agencia. Las notas de la versión de AMS360 enumeran los formularios ACORD 80 que incluye: el base 2016/11, más ACORD 80FL (2022/05), 80WA (2021/06), 80NY (2022/02) y 80NV (2022/01) (Vertafore AMS360 23R1 release notes). Una agencia puede, por tanto, generar un 2016/11 perfectamente válido mientras el portal de la aseguradora solicita el 2026/03, y ninguna de las dos partes está haciendo nada mal. La discrepancia la detecta la validación de la carga o una persona, y ambas cuestan un día.

La regla práctica es identificar la edición y la versión estatal antes de leer un solo campo, y luego anclar la lectura a los encabezados de sección en lugar de a las posiciones de página. Una sección de incendios forestales que aparece en la página 5 de un archivo y no existe en otro no es un caso límite en California. Es el documento.

Quince secciones, y el envío solo depende de una parte de cada una

El formulario se compone de unas quince secciones etiquetadas, y un envío depende de los pocos campos de cada una sobre los que actúa un sistema de enrutamiento, tarificación, elegibilidad o facturación. Leer cada casilla no es lo mismo que leer el formulario. La tabla siguiente agrupa las secciones según lo que ocurre con los datos después de que la solicitud sale del agente.

Dos de esas filas deciden si el resto de la hoja es utilizable. El bloque de tarificación contiene los valores que ponen precio al riesgo, y está escrito en el vocabulario del formulario, no en el del Carrier. El bloque de Loss History es el que puede ser numéricamente correcto y aun así estar mal, porque lo que importa es una página que puede no haber llegado.

Construction Type son tres casillas y un porcentaje, y Masonry Veneer sigue siendo Frame

El bloque de construcción pide Frame, Masonry o Masonry Veneer y un porcentaje, y ninguna de esas tres respuestas es una clase de construcción ISO. El porcentaje está ahí porque las casas son mixtas: una ampliación de entramado de madera sobre una casa de mampostería, un frente de mampostería sobre una estructura de entramado. El bloque describe materiales. No devuelve un código de tarificación.

El código de tarificación que usan la mayoría de los Carrier proviene de las categorías de construcción ISO, que van de ISO Class 1 Frame a ISO Class 6 Fire Resistive. ISO Class 1 se define como muros exteriores de madera, brick veneer, stone veneer, wood ironclad o stucco sobre madera (IRMI, ISO building construction categories). Un colonial con frente de ladrillo y entramado de madera es ISO Class 1. La casilla separada Masonry Veneer del formulario describe el revestimiento, no la estructura, por lo que una casa puede estar marcada como "Masonry Veneer" y aun así tarificarse como Frame.

Tampoco todos los Carrier tarifican según las clases ISO. Muchos asignan la clase ISO a sus propios símbolos de construcción, y esa asignación pertenece al Carrier. Eso deja a la agencia con una respuesta que debe pasar por una tabla que no le pertenece. Si su extracción reduce todo esto a una sola columna "Construction Type", la asignación se destruye justo en el punto donde más se necesita. La solicitud también pasa a formar parte del expediente de la póliza, por lo que la descripción de construcción puede cotejarse con la estructura después de una pérdida.

Una casa con frente de ladrillo y entramado de madera es ISO Class 1. Una lectura que devuelve Masonry porque la página menciona ladrillo ha trasladado el riesgo a una clase más barata, y el error sobrevive a todos los totales de la hoja.

Protection Class se asigna a la dirección, por lo que el campo suele quedar en blanco

El campo de Protection Class es el que se deja vacío con más frecuencia, porque el número se asigna a la ubicación y no lo deduce quien completa el formulario. Protection Class va de 1 a 10, donde 1 es la mejor protegida y 10 significa que no hay protección contra incendios acreditable. No es un juicio que el agente haga en la mesa de la cocina.

En el formulario se ubica en el bloque de tarificación junto al territorio, el nombre y el código del distrito de bomberos, el número de divisiones y unidades de bomberos, y la distancia al hidrante y a la estación de bomberos en millas y pies. La clase en sí proviene de la oficina de tarificación de esa dirección. El agente que no la consulta la deja en blanco, la copia de una póliza anterior de la misma calle o la arrastra desde la página de declaraciones de un Carrier anterior. Las tres cosas ocurren, y la página se ve igual en cada caso.

El manejo de los espacios en blanco es donde una hoja de cálculo limpia se convierte en una incorrecta. Un Protection Class en blanco debe permanecer en blanco y marcarse. Si la columna escribe 10, o 0, o "none", el Underwriter lee una propiedad no asegurable que no existe, y la solicitud pasa a la cola de excepciones por el motivo equivocado. El mismo bloque de tarificación incluye la distancia al agua de marea en millas y pies, que determina la elegibilidad costera y los Deductible por tormenta con nombre, y es igual de fácil de omitir.

Las distancias al hidrante y a la estación son la evidencia que usa una mesa para verificar una clase en la que no confía. Extráigalas junto con la clase, y la verificación puede hacerse desde la hoja. Extraiga solo la clase, y alguien todavía tendrá que abrir el PDF.

Loss History tiene un período de revisión en blanco y una segunda página

La pregunta de Loss History solicita siniestros "durante los últimos ___ años", y el número no está impreso en el formulario. El espacio en blanco lo completa la versión estatal o el Carrier, por lo que el período no siempre es de tres años, que es lo que imprimían las ediciones anteriores. Suponer un período fijo de tres años lee el período incorrecto en cualquier formulario donde el espacio en blanco indique otra cosa, y nada en la página le indicará que fue un error.

La tabla bajo la pregunta contiene un número fijo de filas de siniestros: número de categoría, fecha, tipo, descripción, monto pagado, si fue disputado y por quién. Cuando los siniestros superan esas filas, el resto llega como una hoja de observaciones adicionales ACORD 101, un loss run del Carrier o un segundo escaneo. La sección de observaciones y anexos del formulario es donde eso se refleja: ACORD 101 para más espacio, ACORD 45 para más intereses adicionales.

Las iniciales del solicitante aparecen junto al sí o al no. Un espacio en blanco no significa "ninguno". Una respuesta sin iniciales es una solicitud incompleta, y tratarla como un solicitante sin siniestros es el error de lectura más costoso en este documento, porque todos los números de la hoja seguirán cuadrando.

El período de comparación lo empeora. La base de datos C.L.U.E. reporta hasta siete años de reclamos de seguro de vivienda (Consumer Financial Protection Bureau), por lo que la visión del Underwriter es más amplia que la del formulario. Un siniestro que nunca se declaró surge como una discrepancia entre la solicitud y el historial de reclamos, y la redacción del propio formulario, "haya sido pagado o no por el seguro", elimina la defensa de que no le costó nada al Carrier. Para saber cómo se realiza esa comparación del lado de los reclamos, consulte la guía de extracción de reclamos de seguros.

Una página de continuación omitida produce una hoja limpia, un conteo de siniestros de cero y ningún error en ninguna parte del proceso. Nada en el flujo posterior sabe que existió una página.

Una solicitud no es una fila

Una segunda vivienda, una vivienda alquilada o una propiedad de temporada convierten una solicitud en dos o más ubicaciones, y tanto la tabla de coberturas como el bloque de tarificación se organizan por número LOC. El listado de ubicaciones enumera cada dirección. La Coverage A a la F se introduce por ubicación. El bloque de tarificación se repite por ubicación. Una solicitud aplanada en una sola fila tiene que volver a dividirse por quien la recibe.

Los Deductible son un conjunto más que un valor. Base, viento y granizo, robo, y tormenta con nombre o huracán llevan cada uno su propio importe, y el Deductible por huracán lleva un porcentaje y un máximo además de una cifra en dólares. Una sola columna "Deductible" conserva el importe base y pierde el porcentaje que cambia la prima costera, que suele ser la cifra de la que depende la cotización.

Los intereses adicionales se multiplican de la misma forma. Un acreedor hipotecario y un segundo titular de gravamen pueden figurar ambos en una misma ubicación, y todo lo que exceda las filas impresas va en un anexo de intereses adicionales ACORD 45. Que el acreedor hipotecario pague la prima es un dato de facturación, no un nombre que archivar.

Decida el Row Grain antes de nombrar una sola columna. El grano de solicitud da una fila por envío y es más fácil de leer. El Location Grain da una fila por vivienda con los campos del solicitante y de la póliza repetidos, y suele implicar menos retrabajo porque el sistema de tarificación del Carrier ya funciona así.

La escritura a mano y las casillas son donde el formulario deja de estar estructurado

Las lecturas más arriesgadas en un ACORD 80 no son los campos de texto largos, sino los estados de las casillas y las iniciales, porque una marca cambia un dato de tarificación. Un nombre de calle incorrecto es visible para quien revisa la fila. Un "sí" omitido en una cama elástica o un negocio en el inmueble no lo es.

Los archivos llegan como PDF rellenables con texto incrustado, copias impresas y escaneadas, fotos de teléfono y faxes. Los rellenables son el caso fácil. El resto requiere leer el formulario como imagen, y las partes difíciles son siempre las mismas: la triple opción de Construction Type, las casillas incluidas y excluidas, el tipo de Deductible, los números de SSN y las fechas de nacimiento escritos en una casilla por carácter, las iniciales del solicitante junto al Loss History y el aviso de privacidad, y la explicación manuscrita que sigue a cada "sí" en la sección de información general.

El Model Tier importa aquí de una forma en que no lo hace en una factura impresa. El nivel estándar se encarga de formularios impresos limpios. La escritura densa, las copias enviadas por fax y los diseños complejos son para lo que existen los niveles superiores, y la facturación por Batch se fija en el nivel vigente cuando se envía el Batch.

El Review Mode con cuadros delimitadores es la otra mitad de la respuesta. Al pasar el cursor o hacer clic en una celda se resalta en la página original la región de la que procede el valor, y al hacer clic en una región se vuelve a la celda. Usado en los veinte campos que deciden el envío, sustituye la comparación línea por línea con el escaneo. Usado en los varios cientos, es solo una forma más lenta de leer el formulario.

Cree el conjunto de columnas por sección y mantenga dos columnas siempre que un campo necesite traducción

Los nombres de las columnas son todo el diseño, porque la extracción busca el significado de un nombre de columna en lugar de una posición fija en la página. Eso es lo que significa Extracción de Columnas Personalizadas en la práctica: usted escribe los nombres de campo que desea, como "Coverage A Dwelling Limit" o "Protection Class", y el modelo encuentra el valor correspondiente dondequiera que esté en esa edición o versión estatal. No hay ningún mapa de zonas que volver a dibujar cuando cambia el diseño, por lo que un formulario 2026/03 y un formulario 2016/11 pueden leerse con el mismo conjunto de columnas.

El Batch es lo que convierte el diseño en una cola de trabajo. Cargue un mes de solicitudes de una sola vez y los resultados se fusionan en una única tabla, una fila por ubicación, con el Producer y el Carrier repetidos en cada fila. Ordenada por Producer, la hoja responde a una pregunta que ninguna solicitud individual puede responder: qué agencia sigue dejando en blanco la Protection Class y cuál sigue enviando formularios 2016/11.

Dos ajustes hacen el resto del ensamblaje. Una columna calculada puede restar la cifra de Replacement Cost del límite de Coverage A en el mismo formulario y devolver la diferencia, o devolver "OK" cuando coinciden, lo que convierte una comparación manual en un filtro. La fusión de varias páginas puede volver a integrar una hoja de continuación escaneada por separado en la misma fila cuando las páginas comparten una referencia como un número de póliza o el nombre del solicitante. Si la segunda página no repite esa referencia, no se fusionará, por lo que el Loss Count aún debe verificarse contra lo que llegó.

Lee la solicitud y se detiene antes de la tarificación, la validación y la escritura de vuelta

La extracción coloca la solicitud en una tabla con los campos que usted solicitó, y toda decisión sobre el riesgo queda en manos de una persona o del sistema del Carrier. Vale la pena enunciar el límite con claridad, porque el modo de fallo con un documento de esta trascendencia es la confianza excesiva, no la falta de confianza.

• Sin tarificación ni prima. La hoja contiene los datos de entrada, no el precio.
• Sin decisión de elegibilidad ni de suscripción. No aceptará, rechazará ni remitirá un riesgo.
• Sin validación de ACORD. No le indicará que falta un campo obligatorio para esta edición o estado, a menos que usted cree una columna que exponga esa ausencia.
• Sin verificación de edición. No puede indicarle que el formulario es la versión incorrecta para el Carrier; esa es tarea del administrador del AMS.
• Sin integración con AMS. La salida es Excel, CSV o JSON, o la API v1 si desea enviar los datos a su propio sistema.
• Sin conocimiento de una página que nunca llegó. Una hoja de continuación faltante es invisible a menos que el conjunto de columnas haga contable esa ausencia.

Una nota de manejo que importa más aquí que en la mayoría de los formularios: la página 1 contiene números de Seguro Social y fechas de nacimiento. Decida si esas columnas son necesarias antes del primer Batch, porque una hoja de cálculo que no las contiene no puede filtrarlas. Si el Carrier necesita los identificadores, manténgalos en una hoja separada con su propio control de acceso.

Preguntas frecuentes

¿Para qué se usa un ACORD 80? Es la Solicitud de Propietario de Vivienda, el formulario estándar que un agente completa con un solicitante para pedir una cotización o póliza de propietario de vivienda. Registra al solicitante, la propiedad y cómo está construida y protegida, la cobertura solicitada, el seguro y las pérdidas previas, y el acreedor hipotecario. Es una solicitud, no una póliza, y la cobertura se vincula solo cuando se completa la sección del Binder.

¿Por qué hay tantas versiones del mismo formulario? ACORD publica un formulario base de alcance nacional y versiones estatales donde las reglas de un estado exigen campos o avisos distintos. California agregó una sección de mitigación de incendios forestales, Misisipi y Arkansas agregaron datos de FORTIFIED y mitigación de viento, y otros estados incluyen sus propios avisos y períodos de revisión retrospectiva.

¿Qué edición debo extraer, 2016/11 o 2026/03? La edición que el Carrier acepte y, cada vez más, esa es la 2026/03. Lea el pie de página del archivo en lugar de suponer, porque el AMS de una agencia puede seguir generando la 2016/11 mientras el portal espera el formulario actual. Extraiga la edición en su propia columna para que la discrepancia sea visible.

¿Puede una IA leer un ACORD 80 manuscrito o escaneado? Sí, con salvedades. Los formularios impresos y rellenables son el caso confiable. Las respuestas manuscritas, las copias enviadas por fax y las fotografías necesitan un nivel de procesamiento más potente, y los campos con mayor probabilidad de lectura errónea son las casillas de verificación y las iniciales, no el texto mecanografiado.

¿Cuántas filas debería producir un ACORD 80? Una por ubicación, no una por formulario. Una segunda vivienda o una vivienda alquilada agrega una ubicación con sus propios límites de cobertura, datos de tarificación y Deductible. Si usted construye con granularidad de solicitud, prevea la división en etapas posteriores.

¿Esto reemplaza la validación de ACORD o mi AMS? No. Lee los campos que usted solicita y los devuelve como una tabla. No verifica el formulario contra las reglas de campos de ACORD, no tarifica el riesgo, no decide la elegibilidad ni escribe en un sistema de gestión de agencias.

El resto de la familia ACORD tiene la misma forma y distintos puntos de fallo. Las solicitudes comerciales basadas en ACORD 125 y 126 incluyen las secciones de propiedad y responsabilidad civil que los acompañan, la evidencia para un prestamista pasa por ACORD 27, y los certificados siguen sus propias reglas en la guía de ACORD 25. Si todavía está eligiendo una herramienta en lugar de un conjunto de columnas, la comparación de software de procesamiento de documentos de seguros cubre en qué se diferencian las categorías.

La forma más rápida de ver cuáles de estos campos faltan en sus propias solicitudes es procesar un lote y ordenar por los espacios en blanco. Suba un conjunto de solicitudes de propietarios de vivienda ACORD 80, nombre las columnas por sección y observe qué vuelve vacío.

Pruébelo con sus propias solicitudes