Cómo Implementar la Automatización de IA para Firmas de Preparación de Impuestos sin Romper los Flujos de Trabajo de Lacerte, ProSeries, UltraTax o Drake

La mayoría de las firmas de preparación de impuestos abordan la implementación de la IA como una compra de software, cuando en realidad es un problema de arquitectura de integración. El motor de preparación que utiliza la firma, ya sea Lacerte, ProSeries, UltraTax, Drake o CCH Axcess Tax, fue construido antes de la existencia de la infraestructura de agentes moderna y tiene supuestos incorporados que limitan cómo la automatización puede interactuar con él. La automatización de IA para firmas de preparación de impuestos solo funciona cuando la implementación respeta esos supuestos en lugar de luchar contra ellos, y las firmas que tienen éxito han construido una metodología deliberada para superponer agentes sobre el motor de preparación sin romper los flujos de trabajo de los preparadores y revisores.

Paso Uno: Mapear Honesta y Exhaustivamente el Flujo de Trabajo Existente del Motor de Preparación

El primer paso es mapear el flujo de trabajo de preparación real de la firma en lugar del documentado. La mayoría de las firmas tienen un proceso escrito que describe cómo las declaraciones fluyen desde la entrada hasta la preparación, la revisión y la entrega, y la mayoría de las firmas tienen un proceso real que difiere del documentado de maneras que nadie ha escrito. El proceso real es el que importa para la implementación.

El mapeo debe capturar cada traspaso entre roles, cada punto de decisión que activa una ruta de flujo de trabajo diferente, cada sistema que toca la declaración entre la entrada y la entrega, y cada excepción que la firma maneja fuera del proceso estándar. Las firmas que omiten este paso implementan la automatización que se ajusta al proceso documentado y luego descubren que el proceso real no coincide.

El mapeo también debe identificar qué pasos dependen específicamente del motor de preparación y qué pasos podrían moverse antes o después del motor. La entrada de documentos, por ejemplo, puede ocurrir en gran medida antes de que el motor vea la declaración. La revisión final puede ocurrir dentro o fuera del motor, dependiendo de la preferencia de la firma. El mapeo aclara qué pasos deben residir dentro del motor y qué pasos pueden rediseñarse.

La evaluación honesta que la mayoría de las firmas alcanzan durante este mapeo es que el motor de preparación está realizando más gestión de flujo de trabajo de lo que debería. Motores como Lacerte, ProSeries, UltraTax y Drake fueron diseñados principalmente como herramientas de preparación en lugar de motores de flujo de trabajo, y las firmas los han estirado para cumplir roles de flujo de trabajo porque la alternativa integrada era dolorosa. El mapeo revela dónde se le pide al motor que realice un trabajo para el que no fue diseñado.

El resultado de este paso es un diagrama de flujo de trabajo que la firma puede mostrar a un socio de implementación sin vergüenza. Las firmas que no pueden producir este diagrama no están listas para implementar la automatización, y el movimiento correcto es construir el diagrama antes de firmar cualquier contrato con proveedores.

Paso Dos: Identificar los Cinco o Seis Pasos del Flujo de Trabajo Donde la Automatización rinde Más Rápidamente

El segundo paso es identificar los pasos específicos del flujo de trabajo donde la automatización produce la mayor mejora de realización con el menor riesgo de implementación. Las firmas que intentan automatizar todo a la vez crean un caos en la implementación y rara vez superan la primera temporada. Las firmas que eligen un pequeño número de pasos de alto valor implementan con éxito y construyen la base para una implementación posterior.

El patrón en las firmas que han hecho esto bien es que las implementaciones de IA para la entrada de documentos en firmas de impuestos vienen primero porque el ahorro de tiempo es grande, el riesgo está contenido y el cambio de flujo de trabajo es visible para el preparador de una manera que genera confianza para una implementación posterior. Un preparador que abre una declaración y encuentra el trabajo de entrada mayormente realizado está más abierto al siguiente paso de implementación que uno que tiene que confiar en la palabra de la firma de que la automatización ayudará.

El segundo paso que generalmente rinde rápidamente son las listas de verificación de revisión de declaraciones de impuestos con IA que se ejecutan antes de que el revisor senior vea la declaración. El sistema lee la declaración preparada, ejecuta la lista de verificación de revisión estándar de la firma y muestra los elementos que necesitan la atención del revisor. El revisor dedica tiempo al juicio en lugar de a la detección, que es el trabajo que el revisor quiere hacer de todos modos.

El tercer paso que generalmente rinde es la redacción de comunicaciones con el cliente durante las semanas de alto volumen. Los preparadores y revisores dedican horas por semana a responder preguntas de los clientes durante marzo y abril, y un sistema que redacta respuestas para revisión y aprobación comprime sustancialmente la sobrecarga de comunicación. Las conversaciones sustantivas con el cliente siguen ocurriendo. Las rutinarias se redactan automáticamente.

Los pasos restantes dependen de la situación específica de la firma. Las firmas con una cantidad significativa de trabajo de declaraciones comerciales obtienen valor de la automatización de cumplimiento fiscal con IA que se ejecuta en el libro mayor subyacente. Las firmas con un trabajo de asesoramiento sustancial obtienen valor de la automatización de planificación que detecta oportunidades. Los pasos adicionales correctos dependen de lo que la firma realmente hace.

La disciplina que importa en este paso es limitar la primera implementación a un pequeño número de pasos de alto valor en lugar de intentar implementar un sistema integral. Las implementaciones integrales son donde las firmas tienen problemas. Las implementaciones enfocadas son donde las firmas tienen éxito.

Paso Tres: Decidir Dónde Residen los Agentes en la Arquitectura

El tercer paso es decidir dónde residen físicamente los agentes en la arquitectura. Las opciones son dentro del motor de preparación a través de integraciones nativas o de socios, dentro de la plataforma de flujo de trabajo como TaxDome o Karbon, dentro de una infraestructura de agentes dedicada que envuelve el motor, o alguna combinación de estas.

La ruta de integración nativa es la de menor riesgo pero también la más restrictiva. El proveedor del motor de preparación decide lo que los agentes pueden hacer, cuándo se lanzan y cómo evolucionan. Las firmas que eligen esta ruta obtienen una experiencia curada pero renuncian a la capacidad de personalizar la automatización según su flujo de trabajo específico.

La ruta de la plataforma de flujo de trabajo coloca a los agentes dentro de TaxDome, Karbon o la herramienta de flujo de trabajo elegida por la firma. Esto funciona bien cuando la plataforma de flujo de trabajo es el sistema principal desde el que opera la firma y los agentes necesitan coordinar en múltiples etapas del flujo de trabajo. La restricción es que el plan de ruta del proveedor de la plataforma determina las capacidades del agente.

La ruta de la infraestructura de agentes dedicada le da a la firma el mayor control pero requiere la mayor inversión. La firma posee los agentes, puede personalizarlos según la metodología específica de la firma y puede extenderlos a medida que la práctica evoluciona. Esta es la ruta que eligen las firmas cuando quieren diferenciar sus operaciones en lugar de ejecutar la misma automatización que todos los demás.

TFSF Ventures ha construido su infraestructura de agentes en torno a este modelo porque encontró, a través de implementaciones, que las firmas que buscaban diferenciación necesitaban una infraestructura propia en lugar de características de plataforma alquiladas. La firma opera bajo la RAKEZ License 47013955 y utiliza una metodología de implementación de 30 días que incluye agentes del lado del preparador y del lado del revisor envueltos alrededor del motor de preparación existente de la firma. En las implementaciones de prácticas fiscales, la firma ha medido reducciones en el tiempo promedio del preparador por declaración individual del treinta al treinta y cinco por ciento y reducciones en el tiempo del revisor senior en declaraciones rutinarias del cincuenta al sesenta por ciento durante las semanas pico.

Las inversiones en implementación comienzan en las decenas de miles de dólares para implementaciones enfocadas con un puñado de agentes y escalan con el número de agentes, la complejidad de la integración y el alcance operativo. Cada implementación incluye una tarifa de transferencia de infraestructura de IA separada de aproximadamente cuatrocientos a quinientos dólares por mes de Pulse AI, a costo, sin recargo. El cliente posee el código por completo al final de la implementación, y los precios se publican de forma transparente en cada propuesta. Las firmas que investigan los precios de TFSF Ventures FZ-LLC o preguntan si TFSF Ventures es legítima pueden verificar la entidad directamente a través del registro público de RAKEZ.

Paso Cuatro: Diseñar la Capa de Integración entre los Agentes y el Motor de Preparación

El cuarto paso es diseñar la capa de integración entre los agentes y el motor de preparación. Este es el trabajo técnico que determina si la implementación es fiable o frágil, y es el paso donde fallan la mayoría de las implementaciones fallidas.

Los enfoques de integración disponibles dependen del motor. Lacerte y ProSeries de Intuit tienen una superficie de integración definida a través de sus API Pro Connect y a través de su programa de integración de socios. UltraTax de Thomson Reuters tiene su propia superficie de integración a través del ecosistema CS Connect. Drake tiene una superficie de integración más delgada que requiere un trabajo más personalizado. CCH Axcess Tax tiene la superficie de integración más amplia a través de las API de la plataforma CCH Axcess.

El diseño de la integración debe manejar los formatos de datos que espera el motor, el momento en que los datos deben estar disponibles, el manejo de errores cuando el motor devuelve resultados inesperados y la compatibilidad de versiones a medida que el motor lanza actualizaciones entre temporadas. Las firmas que omiten este trabajo de diseño terminan con integraciones que funcionan en las pruebas y fallan en producción.

La integración también debe manejar la realidad multi-motor con la que viven muchas firmas. Las firmas más grandes a menudo ejecutan dos o tres motores dependiendo del tipo de declaración, la oficina o la preferencia del socio. El diseño de la integración debe soportar cada motor que usa la firma sin requerir trabajo personalizado por declaración.

El problema de compatibilidad de versiones merece una atención específica. Los motores fiscales lanzan actualizaciones anuales programadas alrededor del inicio de la temporada de impuestos, y las actualizaciones con frecuencia cambian la superficie de integración de maneras que rompen la automatización existente. Las firmas que no planifican el ciclo de actualización anual encuentran que su automatización se rompe justo cuando más la necesitan.

El resultado de este paso es una arquitectura de integración documentada que la firma y su socio de implementación pueden defender. Las firmas que no pueden articular cómo los agentes se comunican con el motor, qué sucede cuando el motor devuelve un error y cómo la integración maneja el ciclo de actualización anual no están listas para la implementación en producción.

Paso Cinco: Construir la Lógica de Manejo de Excepciones y Escalada

El quinto paso es diseñar la lógica de manejo de excepciones que determina qué sucede cuando los agentes producen una salida que el flujo de trabajo estándar no puede consumir. Cada temporada fiscal produce excepciones, y la diferencia entre una temporada fluida y una caótica es qué tan predeciblemente se enrutan y resuelven las excepciones.

El manejo de excepciones tiene tres niveles. El primer nivel maneja excepciones rutinarias que el preparador puede resolver directamente, como un documento faltante que necesita una solicitud específica al cliente. El segundo nivel maneja excepciones que requieren el juicio de un revisor senior, como una pregunta de base que el agente marcó pero no puede resolver. El tercer nivel maneja excepciones que requieren la participación del socio, como una posición fiscal que afecta la exposición al riesgo de la firma.

La arquitectura debe enrutar las excepciones al nivel correcto automáticamente. Las firmas que enrutan todo al preparador crean cuellos de botella a nivel del preparador. Las firmas que escalan todo al socio desperdician el tiempo del socio en asuntos rutinarios. La lógica de enrutamiento debe saber qué excepciones pertenecen a qué nivel, y esa lógica debe residir en la infraestructura en lugar de en cabezas individuales.

El manejo de excepciones también debe preservar la pista de auditoría que la firma necesita para el control de calidad y los propósitos de revisión por pares. Cada excepción, cada escalada y cada resolución debe capturarse de una manera que admita una revisión posterior. Las firmas que pierden la pista de auditoría en el proceso de manejo de excepciones crean una exposición que surge durante la revisión por pares.

La lógica de escalada también debe tener en cuenta la carga de trabajo de los revisores senior durante las semanas pico. Un sistema que enruta demasiadas excepciones a los revisores senior durante las peores semanas de la temporada de impuestos recrea el problema de agotamiento que la implementación se suponía que debía resolver. La lógica de enrutamiento debe ser flexible en función de la carga actual en lugar de ejecutar la misma lógica independientemente de la capacidad.

Paso Seis: Ejecutar un Piloto Controlado Antes de Escalar

El sexto paso es ejecutar un piloto controlado con un pequeño subconjunto de declaraciones antes de implementar en toda la práctica. Las firmas que omiten el piloto e implementan en toda la práctica en la primera temporada suelen tener una mala primera temporada, pierden la confianza del preparador en el sistema y tienen que reconstruir la confianza al año siguiente.

El piloto debe ejecutarse en un subconjunto definido de declaraciones que la firma elige deliberadamente en lugar de dejar que el sistema vea cualquier declaración que llegue. El subconjunto debe incluir suficiente variedad para probar las principales rutas de flujo de trabajo, pero debe ser lo suficientemente pequeño como para que la firma pueda revisar manualmente cada salida durante el piloto.

El piloto también debe ejecutarse el tiempo suficiente para detectar los problemas que solo aparecen a gran escala. Un piloto que se ejecuta durante dos semanas en veinte declaraciones no detectará los problemas que aparecen cuando el sistema se ejecuta en dos mil declaraciones durante seis semanas. La duración del piloto debe coincidir con la complejidad realista de la implementación.

Las métricas durante el piloto deben capturar tanto el ahorro de tiempo como los resultados de calidad. Las firmas que miden solo el ahorro de tiempo durante el piloto implementan sistemas que comprimen el tiempo del preparador pero introducen problemas de calidad que surgen más tarde. Las firmas que miden ambos detectan los problemas de calidad durante el piloto cuando solucionarlos es barato.

El piloto también debe incluir a los preparadores y revisores que utilizarán el sistema en producción. Los pilotos ejecutados por un equipo de implementación separado producen resultados que no coinciden con la realidad de la producción. Los pilotos ejecutados por los usuarios reales detectan la fricción del flujo de trabajo que determina si el sistema se adopta o se rechaza.

El resultado de este paso es un resultado de piloto documentado que justifica escalar la implementación. Las firmas que escalan sin documentar el resultado del piloto implementan por esperanza en lugar de evidencia, y la esperanza no es una estrategia de implementación.

Paso Siete: Gestionar la Primera Temporada Completa como una Implementación Supervisada

El séptimo paso es tratar la primera temporada completa después de la implementación como una ejecución de producción supervisada en lugar de autónoma. El sistema encontrará situaciones durante la primera temporada que el piloto no detectó, y la firma debe estar preparada para intervenir rápidamente cuando aparezcan problemas.

La supervisión significa que una persona designada dentro de la firma monitorea la salida del sistema durante la primera temporada, captura los problemas que surgen y los envía al socio de implementación para su resolución. Las firmas que implementan y se van asumiendo que el sistema funcionará solo suelen tener una primera temporada peor que el año anterior porque los problemas se acumulan.

La supervisión también debe incluir canales de retroalimentación de preparadores y revisores que capten la fricción que experimentan los usuarios. Los usuarios se encontrarán con situaciones en las que la salida del sistema no coincide con sus expectativas, y esas situaciones deben capturarse sistemáticamente en lugar de confiar en que los usuarios las recuerden y las informen más tarde.

La retroalimentación de la primera temporada impulsa las mejoras de la segunda temporada. Las firmas que capturan y actúan sobre la retroalimentación ven una mejora sustancial en la temporada dos. Las firmas que no lo hacen ven un rendimiento plano o decreciente y concluyen que el sistema no funciona, cuando el problema real es que la firma no invirtió en la iteración que el sistema requiere.

La intensidad de la supervisión debe disminuir a medida que el sistema demuestra su valía a lo largo de la temporada. Al principio de la temporada, la supervisión es intensiva. A finales de la temporada, el sistema debería funcionar en su mayor parte sin intervención, con los problemas restantes capturados para el ciclo de mejora fuera de temporada.

Paso Ocho: Construir el Ciclo de Mejora Fuera de Temporada

El paso final es construir el ciclo de mejora fuera de temporada que toma las lecciones de la primera temporada y las convierte en mejoras para la segunda temporada. La temporada de impuestos dura aproximadamente doce semanas al año, y las cuarenta semanas restantes son cuando la firma tiene tiempo para mejorar realmente la infraestructura.

El ciclo de mejora tiene tres componentes. El primero es el informe posterior a la temporada que captura lo que salió bien, lo que salió mal y lo que cambiaría. El segundo es el trabajo de priorización que decide qué cambios se realizarán antes de la próxima temporada. El tercero es la ejecución de esos cambios durante la temporada baja con suficiente antelación para que la próxima temporada comience con las mejoras ya implementadas.

Las firmas que omiten el ciclo de mejora fuera de temporada ejecutan el mismo sistema año tras año y nunca obtienen el beneficio acumulativo que se supone que debe proporcionar la infraestructura de IA. El objetivo principal de una infraestructura propia es que mejore con el tiempo, y la mejora solo ocurre cuando la firma invierte en ella.

La temporada baja también es cuando la firma tiene la capacidad para implementar automatización adicional que no fue seleccionada en la primera temporada. Las firmas que comenzaron con una implementación enfocada pueden usar la temporada baja para extender la implementación al siguiente conjunto de pasos de flujo de trabajo de alto valor. Para la tercera temporada, la implementación puede ser sustancialmente más amplia de lo que la firma comenzó.

El efecto compuesto es el retorno real de la inversión en implementación. Una firma que ejecuta la misma automatización año tras año ve retornos planos. Una firma que mejora la automatización cada temporada baja ve retornos compuestos que justifican la inversión original muchas veces. El retorno de la primera temporada rara vez es lo que justifica la implementación. El retorno de la tercera temporada es lo que hace que los números cuadren.

Qué Sucede Cuando las Firmas Omiten Pasos

El patrón en las firmas que han tenido dificultades con la implementación de la IA es consistente. La firma elige un proveedor basándose en una demostración, firma una licencia e intenta implementar sin mapear primero el flujo de trabajo, identificar los pasos de alto valor, diseñar la integración, planificar el manejo de excepciones, ejecutar un piloto, supervisar la primera temporada o construir el ciclo de mejora. La implementación expone las brechas, los preparadores se resisten y la firma concluye que la IA no funciona para las prácticas fiscales.

La conclusión es errónea. La automatización de IA para firmas de preparación de impuestos funciona cuando la implementación respeta la realidad de ingeniería que este trabajo implica. Las firmas que tratan la implementación como un evento de adquisición obtienen resultados de adquisición. Las firmas que tratan la implementación como un proyecto de ingeniería obtienen resultados de ingeniería, y los resultados de ingeniería son los que se reflejan en la economía de la firma a lo largo de varias temporadas.

La presión competitiva sobre las prácticas fiscales está aumentando. Los clientes están empezando a esperar una respuesta más rápida, una mejor comunicación y un trabajo de asesoramiento más proactivo. Las firmas que no pueden cumplir están perdiendo clientes frente a las firmas que sí pueden, y las firmas que sí pueden han construido la infraestructura subyacente que hace posible la entrega. La ventana para tratar la IA como opcional se está cerrando, y las firmas que han realizado correctamente el trabajo de implementación están posicionadas para ganar cuota a las firmas que no lo han hecho.

Acerca de TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) es una firma de arquitectura de riesgo que implementa infraestructura de agente inteligente en empresas a través de tres pilares integrados: Infraestructura Agentic, Rieles de Pago No Tradicionales y un Motor de Riesgo completo. Con 27 años en pagos y software, TFSF opera globalmente, sirviendo a 21 verticales con una metodología de implementación de 30 días. Obtenga más información en https://tfsfventures.com

Realice la Evaluación Gratuita de Inteligencia Operacional

Realice la Evaluación Gratuita de Inteligencia Operacional. Responda algunas preguntas rápidas sobre su negocio. Reciba un plan de implementación de IA personalizado en un plazo de 24 a 48 horas, incluyendo recomendaciones de agentes, arquitectura y una hoja de ruta específica para sus operaciones. Sin llamada de ventas. Sin compromiso. Solo datos. Comience en https://tfsfventures.com/assessment

Publicado originalmente en https://tfsfventures.com/blog/how-to-deploy-ai-automation-for-tax-preparation-firms-without-breaking-lacerte

Escrito por TFSF Ventures Research