La integración con QuickBooks es la función que toda herramienta dice tener y casi nadie entrega de verdad

Toda herramienta de operaciones dice que integra con QuickBooks Online.

Un comprador en un demo pregunta qué significa eso y recibe una respuesta segura. Seis meses después, descubre lo que “integración” realmente era. Una exportación a CSV que tiene que correr a mano. Un OAuth de un solo disparo que se rompió cuando el token expiró y nunca se refrescó. Un stub que empujó clientes pero no facturas. Una “sincronización” que corría una vez por noche y dejaba caer la mitad de los registros porque la API la limitaba.

“¿Integran con QuickBooks?” es la pregunta que hace todo comprador de operaciones. La respuesta honesta toma más de lo que permite el demo. Así que vamos a escribir lo que de verdad entregamos, en las cuatro etapas en que lo entregamos, y lo que cada etapa hizo cuando la conexión de prueba falló.

Por qué esta pregunta es difícil de contestar en una sola frase

QuickBooks Online no es una sola superficie. Es una lista de clientes, un catálogo de items de servicio, una jerarquía de clases, un libro de facturas, un libro de pagos y un libro de asientos contables. Integrar con él significa elegir a cuáles de esas superficies escribes, de cuáles lees, en qué dirección corre la fuente de verdad y qué pasa cuando los dos sistemas no están de acuerdo.

La mayoría de las herramientas que dicen integrar con QBO tomaron una de esas decisiones y se detuvieron ahí. Sincronizan clientes. No sincronizan facturas. Sincronizan facturas en una dirección pero el rev rec se queda en una hoja de cálculo. Empujan pagos pero no pueden hacer match a un pago entrante que vino por un procesador distinto.

El comprador descubre qué decisión tomó el proveedor en producción, al pegar contra la costura.

Etapa 39, la conexión en sí

QBO-CORE-a es OAuth en /admin/integrations/qbo. El admin conecta el archivo de la empresa, los tokens caen encriptados y el auto-refresh corre en horario, así que el token no expira en silencio a mitad de un trimestre.

La dirección de empuje es de una vía, de PartnerView a QBO. Clientes, items de servicio y clases de práctica se mandan. Las facturas se mandan, pero solo después de una compuerta de envío y aprobación. Una factura se redacta en PartnerView. Un líder de finanzas la revisa. El empuje a QBO es una acción deliberada, no un trabajo en segundo plano. Lo que cae en el libro de QBO es lo que finanzas aprobó.

Cuando la conexión de prueba falló, la compuerta bloqueó el empuje. La factura se quedó en borrador. El error apareció en la cola del admin, no en silencio en el log de errores de QBO.

Etapa 40, sincronización de pagos que no pierde pagos

QBO-PAYMENT-a es primario por webhook, con un respaldo de polling cada 15 minutos.

El webhook es el camino rápido. Cuando un pago cae en QBO, el webhook se dispara y la factura que hace match en PartnerView se marca pagada en segundos. El respaldo de polling es la red de seguridad. Cada 15 minutos, un trabajo reconcilia pagos recientes de QBO contra facturas de PartnerView, por si el webhook dejó caer alguno.

El caso duro es el pago sin match. Un pago cae en QBO que no coincide con ninguna factura en el archivo de PartnerView, porque el trato se registró fuera del sistema, o el cliente pagó contra una factura que fue editada, o alguien aplicó el pago al cliente equivocado en QBO. La mayoría de las herramientas fallan eso en silencio. El pago cae, nada hace match, y los libros se reconcilian seis semanas después cuando finanzas se da cuenta.

El pago sin match en PartnerView va a una cola de reconciliación manual. Finanzas ve una lista. Hacen match a cada pago con la factura correcta, o lo dejan para el siguiente pase con una nota. Nada se pierde. Nada se misasigna en silencio.

Etapa 41, reconocimiento de ingresos que cuadra por construcción

QBO-REVREC-a postea asientos contables mensuales de reconocimiento de ingresos desde PartnerView a QBO.

La matemática es por modelo de ingreso. Un trato de suscripción se reconoce de forma proporcional. Un trato de hitos se reconoce por hito. Un trato T&M se reconoce conforme se registra el tiempo. El cronograma de reconocimiento vive en el trato. El asiento contable postea el monto reconocido contra las cuentas correctas, con la clase correcta en cada línea.

Antes de que se persista cualquier asiento contable, corre una aserción dura. Débito igual a crédito. Los dos lados del asiento se suman y se comparan. Si no son iguales al centavo, el asiento se rechaza antes de tocar el libro. Un asiento contable desbalanceado no puede existir en este sistema, ni siquiera como borrador.

El caso de cambio de cronograma es el que la mayoría de las herramientas manejan mal. El cronograma de reconocimiento de un trato cambia a media corriente. La mayoría de las herramientas editan el asiento posteado del mes anterior, lo que estropea la historia del libro, o no hacen nada, lo que deja los libros mal. PartnerView postea un asiento de reversa contra el original, y postea el nuevo asiento. La historia del libro se preserva. El periodo actual refleja el cronograma corregido.

Etapa 42, la documentación que prueba el límite

REVENUE-FLOW-DOCS-a es la descripción de dónde está la línea. PartnerView es dueño del ciclo de trato a factura. QuickBooks Online sigue siendo el sistema de registro para el libro. Los asientos contables fluyen en una vía, de PartnerView a QBO. Los cambios a nivel de cuenta se hacen en QBO, no en PartnerView. El catálogo de cuentas es de QBO.

Qué significa “donde importa” en la práctica: el contador de la firma abre QuickBooks cada mañana, no PartnerView, porque esa es la herramienta correcta para los libros. El dueño del trato abre PartnerView, no QuickBooks, porque el trato está en PartnerView. Los dos sistemas intercambian los artefactos correctos en la dirección correcta, y el límite está documentado para que nadie tenga que adivinar dónde hacer un cambio.

Lo que PartnerView entrega

La integración con QBO son cuatro etapas, todas vivas. OAuth y empuje de una vía de clientes, items de servicio, clases y facturas aprobadas por una compuerta de envío, aprobación y empuje. Sincronización de pagos primaria por webhook con respaldo de polling y una cola de reconciliación manual para pagos sin match. Asientos contables mensuales de reconocimiento de ingresos balanceados por construcción con asientos de reversa en cambios de cronograma. Un límite documentado que mantiene el libro en QBO y el ciclo del trato en PartnerView.

La respuesta honesta a “¿integran con QuickBooks?” es sí, en estas cuatro formas específicas, con estos modos de falla específicos. Esa respuesta es más larga que una respuesta de llamada de ventas. Es la respuesta que el comprador necesita.