Proceso procure to pay: pasos, documentos y cómo automatizarlo

El proceso procure to pay (P2P, de la compra al pago) es la secuencia de pasos que sigue una empresa desde que alguien necesita comprar algo hasta que el proveedor recibe su pago y ese pago queda conciliado. En un fabricante o distribuidor abarca la requisición, la búsqueda de proveedores, la orden de compra, la confirmación del proveedor, la recepción de la mercancía, la factura del proveedor y su conciliación, la aprobación, el pago y la conciliación bancaria. Cada paso comienza con un documento, y cada documento tiene que llegar a la pantalla correcta del ERP antes de que pueda empezar el siguiente.

Esta guía recorre el ciclo procure to pay paso a paso, indica el documento que llega en cada etapa y dónde se registra en Epicor Kinetic, y muestra dónde aplica la automatización, qué medir y dónde suele fallar el proceso. Su ciclo hermano del lado de ventas es el proceso order to cash, que va de la cotización al cliente al cobro aplicado.

Los pasos del procure to pay

1. Requisición

Surge una necesidad: el MRP sugiere una compra para una orden de trabajo o para reponer inventario, un comprador ve una pieza por debajo de su punto de reorden, o alguien de mantenimiento o de la oficina pide insumos. En Epicor Kinetic, las compras planeadas aparecen como sugerencias de compra, y las solicitudes puntuales pasan por Requisitions, donde se envían a aprobación antes de que un comprador actúe. Las compras que se saltan este paso (un pedido por teléfono, un cargo a tarjeta) llegan después como facturas sin orden de compra detrás.

2. Búsqueda de proveedores y cotización

Para piezas sin proveedor ni precio acordados, el comprador pide cotización a uno o varios proveedores. En Epicor Kinetic esto es RFQ Entry. Las cotizaciones de los proveedores regresan como PDF, correos y hojas de cálculo con los números de parte, unidades, precios por volumen y tiempos de entrega del propio proveedor, y alguien las compara y registra el precio ganador. Para piezas recurrentes, una lista de precios del proveedor sustituye este paso.

3. Orden de compra

El comprador emite la orden de compra en PO Entry: proveedor, líneas, cantidades, unidad de medida, precio, fechas de entrega y, para materiales comprados para una orden de trabajo, la orden y la operación a la que alimentan. Muchas órdenes de compra también nacen de documentos: una cotización del proveedor, una solicitud por correo de producción, una hoja de cálculo con líneas de reposición. La orden de compra es la referencia contra la que se compara cada paso posterior, así que un error aquí (unidad equivocada, precio equivocado, pieza del proveedor equivocada) aparece en la recepción o en la factura.

4. Confirmación del proveedor

El proveedor confirma el pedido, a menudo con cambios: otra fecha prometida, una pieza sustituta, un precio que ya no coincide, un envío dividido. La confirmación llega por correo o PDF, a veces por EDI, y las fechas y precios confirmados deberían actualizarse en la orden de compra en PO Entry. Cuando no se actualizan, planeación trabaja con fechas que el proveedor nunca prometió y la factura después no coincide con la orden de compra.

5. Recepción

La mercancía llega con un packing slip (lista de empaque). El andén de recepción registra lo que llegó contra la entrega de la orden de compra en Receipt Entry: cantidad, unidad, números de lote o de serie, y si va a inventario, a inspección o a una orden de trabajo. Los packing slips usan los números de parte y las unidades del proveedor, pueden cubrir varias órdenes de compra y con frecuencia llegan con faltantes o excedentes. Las recepciones que no se registran a tiempo detienen todo lo que viene después, porque la factura no puede pasar la conciliación a tres vías contra mercancía que el ERP no sabe que llegó.

6. Factura del proveedor y conciliación

Llega la factura del proveedor, normalmente como PDF adjunto a un correo, y cuentas por pagar la registra en AP Invoice Entry. La conciliación es el control de este paso:

• Conciliación a dos vías. La factura se compara con la orden de compra: proveedor correcto, líneas correctas, cantidad y precio según lo pedido. Sirve para servicios y artículos sin recepción física.
• Conciliación a tres vías. La factura se compara con la orden de compra y con la recepción: solo se paga lo que se pidió y realmente se recibió, al precio acordado. Es el control estándar para materiales e inventario.

Las facturas sin orden de compra (servicios públicos, fletes, servicios) se codifican a cuentas contables. Las diferencias de cantidad o precio se convierten en excepciones que alguien tiene que resolver con compras o con el proveedor antes de poder pagar la factura. Nuestra guía para automatizar AP Invoice Entry en Epicor cubre este paso a fondo.

7. Aprobación

Las facturas que coinciden dentro de la tolerancia pueden no necesitar más aprobación; las excepciones y las facturas sin orden de compra van al responsable del presupuesto o al comprador. La aprobación es donde cuentas por pagar espera más a menudo: las facturas se quedan en la bandeja de alguien, se cierran las ventanas de descuento por pronto pago y los proveedores llaman para preguntar por su dinero.

8. Pago

Las facturas aprobadas se seleccionan para pago según vencimiento y condiciones, y se pagan con cheque, ACH, transferencia o tarjeta en AP Payment Entry o mediante una plataforma de pagos. El aviso de pago se envía al proveedor para que aplique el pago a las facturas correctas.

9. Conciliación y reportes

Los pagos se concilian contra el estado de cuenta bancario (Bank Statement Processing en Epicor Kinetic), los estados de cuenta de proveedores se revisan contra el auxiliar de cuentas por pagar, y las recepciones aún no facturadas se provisionan al cierre de mes. Finanzas revisa la antigüedad de saldos de cuentas por pagar, los días de pago a proveedores y el pronóstico de efectivo. Estos reportes son tan buenos como los datos capturados en los pasos 3 a 8.

Paso, documento y pantalla de un vistazo

Dónde aplica la automatización del procure to pay

La automatización del procure to pay es un conjunto de herramientas, cada una cubre una parte del ciclo. La mayoría de las empresas combina varias.

• Funciones de compras del ERP. Epicor Kinetic ya convierte el resultado del MRP en sugerencias de compra, enruta requisiciones, guarda listas de precios de proveedores y compara facturas contra órdenes de compra y recepciones. Use lo que el ERP ya hace antes de comprar alrededor de él.
• Herramientas de compras y abastecimiento. Las plataformas de gestión del gasto y de compras manejan requisiciones, catálogos, alta de proveedores y políticas de aprobación. Ayudan más donde el gasto indirecto (insumos, servicios, software) es grande y disperso.
• Portales de proveedores. Los proveedores que se pueden llevar a un portal confirman pedidos, envían avisos de embarque y suben facturas por su cuenta. Funciona con proveedores grandes y frecuentes y mucho menos con la larga cola que seguirá enviando PDF por correo.
• EDI. Con los proveedores que operan por EDI, las órdenes de compra (850), las confirmaciones (855), los avisos de embarque (856) y las facturas (810) viajan como datos estructurados. Se configura por socio comercial, así que rara vez llega más allá de los proveedores más grandes.
• Agentes de IA para documentos. Los agentes leen los documentos que llegan en cualquier formato (cotizaciones de proveedores, solicitudes de compra, packing slips, facturas) y generan un borrador de la transacción en la pantalla del ERP que le corresponde, para que una persona lo revise. Aquí está Fluent. Cubre los documentos a los que los portales y EDI nunca llegan.
• Plataformas de flujo de cuentas por pagar y de pagos. Herramientas como Stampli, AvidXchange y Tipalti se enfocan en la segunda mitad del ciclo: captura de facturas, flujos de aprobación y pagos a proveedores. Stampli se describe como una plataforma procure to pay con compras, cuentas por pagar y pagos; AvidXchange combina la automatización de cuentas por pagar con una gran red de pagos a proveedores; Tipalti cubre el alta de proveedores, el cumplimiento fiscal y los pagos globales en muchos países y monedas. Si las aprobaciones y las corridas de pago son el cuello de botella, están hechas para eso. Nuestra comparativa de automatización de cuentas por pagar para fabricantes las compara.

La división práctica para la mayoría de los fabricantes medianos: EDI y portales para los proveedores que los usan, una plataforma de flujo de cuentas por pagar o de pagos si las aprobaciones y las corridas de pago son el cuello de botella, y agentes de documentos para todo lo que todavía llega como PDF o correo y se vuelve a teclear.

Métricas del procure to pay

• Tiempo de ciclo de facturas. Tiempo desde que llega la factura hasta que se aprueba para pago (algunos equipos lo miden hasta el pago). Muestra cuánto esperan las facturas antes de que alguien las trabaje.
• Costo por factura. Costo total de la función de cuentas por pagar (tiempo del personal, herramientas, servicios externos) dividido entre el número de facturas procesadas en el periodo. La mayor parte es tiempo del personal capturando y persiguiendo excepciones.
• Tasa de conciliación al primer intento. Porcentaje de facturas con orden de compra que coinciden con la orden de compra y la recepción dentro de la tolerancia al primer intento, sin que nadie las toque. Es la medida más clara de la calidad de los datos aguas arriba: una tasa baja suele apuntar a órdenes de compra con precios equivocados o a recepciones capturadas tarde.
• Tasa de excepciones. Porcentaje de facturas que necesitan intervención humana: una diferencia de precio o cantidad, una orden de compra o recepción faltante, un proveedor desconocido. Mídala por causa, porque cada causa tiene un responsable distinto.
• Días de pago a proveedores (DPO). Cuentas por pagar divididas entre el costo de ventas del periodo, multiplicado por el número de días del periodo. Mide cuánto tarda usted, en promedio, en pagar a sus proveedores. Un valor más alto conserva el efectivo más tiempo, pero compárelo con sus condiciones: pagar mucho después del plazo cuesta buena voluntad y precio con el proveedor.
• Descuentos por pronto pago aprovechados. Descuentos tomados como porcentaje de los descuentos ofrecidos (por ejemplo, 2/10 neto 30). Los descuentos perdidos suelen ser un problema de velocidad de aprobación.
• Cobertura de órdenes de compra. Porcentaje del gasto con proveedores (o de las facturas) respaldado por una orden de compra emitida antes de hacer la compra. Las órdenes de compra emitidas después de que llega la factura no cuentan. Una cobertura baja significa más excepciones, más codificación sin orden de compra y menos control sobre lo que se compra.

Otras medidas útiles son los pagos duplicados detectados, las facturas retenidas por antigüedad y las recepciones aún no facturadas.

Puntos de falla comunes

• Unidades de medida. Usted compra en cajas de 100, almacena por pieza y el proveedor factura por millar. Una recepción o factura capturada en la unidad equivocada se desvía por un factor de 100 o de 1.000, y una conciliación que compara entre unidades distintas no significa nada.
• Números de parte del proveedor. Los packing slips y las facturas usan los números de parte del propio proveedor. Alguien tiene que traducir cada línea a los suyos, y una traducción equivocada recibe o paga el artículo equivocado.
• Precio que cambia de la cotización a la orden de compra y a la factura. Si el precio de la orden de compra no se actualiza después de la confirmación, la factura no pasa la conciliación aunque todos hayan aceptado el precio nuevo.
• Recepciones tardías. La factura llega antes de que se capture la recepción, no pasa la conciliación a tres vías y queda retenida, o se paga con una conciliación a dos vías por mercancía que nunca llegó.
• Facturas duplicadas y doble cobro. La misma factura enviada por correo electrónico y por correo postal, o una segunda factura que cobra una recepción ya facturada. Sin una revisión contra lo que queda por facturar, se pagan las dos.
• Proveedores desconocidos o con cambios. Una nueva dirección de pago o un nuevo dato bancario en una factura es la vía clásica de fraude en pagos. Los cambios en los datos bancarios de un proveedor deben verificarse por otro canal, nunca a partir de la propia factura.
• Volver a teclear entre pasos. La misma línea se captura en la orden de compra, otra vez en la recepción y otra vez en la factura. Cada recaptura es una oportunidad de introducir un error que aparece en la conciliación o en el pago.

Dónde encaja Fluent en el procure to pay

Fluent son agentes de IA que leen documentos de negocio y generan un borrador de la transacción en el ERP para que una persona lo revise. Está construido alrededor de Epicor Kinetic, y tres de sus diez agentes cubren el procure to pay, cada uno con el nombre de la pantalla de Kinetic en la que registra el borrador:

• PO Entry. Lee cotizaciones y confirmaciones de proveedores en cualquier formato y genera la orden de compra en PO Entry, con el proveedor, las condiciones de pago, el comprador, las líneas, las unidades, los precios y los cargos de encabezado resueltos contra Epicor.
• Receipt Entry. Lee packing slips (PDF, escaneos, fotos tomadas en el andén) y genera la recepción en Receipt Entry, con cada línea vinculada a una entrega abierta de la orden de compra, en la unidad en que el proveedor envió.
• AP Invoice Entry. Lee facturas de proveedores y las registra en AP Invoice Entry: proveedor identificado por nombre e identificación fiscal, conciliación a dos y tres vías contra la orden de compra y la recepción, cantidad revisada contra lo que queda por facturar, precio revisado contra el pedido, y cada diferencia mostrada en la línea.

Nada se contabiliza hasta que una persona procesa el borrador. Un flujo de aprobación envía cada documento a las personas que deben aprobarlo, y umbrales como un importe o una variación de precio deciden quién revisa qué. Cada campo leído y cada decisión quedan registrados en el documento. Si ningún proveedor coincide, el documento se genera con una nota de lo que se buscó y espera a una persona. No hay plantillas por proveedor, ni mapeo de campos, ni entrenamiento de modelos: el comportamiento se define con instrucciones escritas, y las correcciones se convierten en instrucciones.

Fluent se conecta a la API REST de Epicor Kinetic desde fuera, sin instalar nada dentro de Epicor, y funciona en instalaciones propias o alojadas por Epicor. Los mismos agentes se ofrecen para otros ERP, entre ellos Prophet 21, SAP Business One, NetSuite, Acumatica y Microsoft Dynamics 365; Epicor Kinetic es donde llega más a fondo.

Dónde no encaja: Fluent no paga a proveedores, y no es una suite de compras, un portal de proveedores ni un traductor EDI. Si sus proveedores operan por EDI, mantenga EDI con ellos. Si el cuello de botella es el ruteo de aprobaciones y las corridas de pago, una plataforma de flujo de cuentas por pagar o de pagos encaja mejor, y puede trabajar después de las facturas que Fluent genera. Fluent cubre los documentos que todavía llegan como PDF, escaneos y correos y se capturan a mano. Para una comparación lado a lado, vea la mejor automatización de cuentas por pagar para Epicor Kinetic.

Véalo con sus propias facturas

Envíe una cotización de proveedor, un packing slip o una factura de proveedor reales y lea el borrador que Fluent genera en Epicor. Empiece por AP Invoice Entry, vea todos los agentes, revise los precios o agende una demo.