FIELD

The present disclosure generally relates to systems and methods for automated invoice reconciliation and payment.

BACKGROUND

Traditional methods of invoice reconciliation often rely on a sequence of purchase orders and invoices prior to payment flowing between the buyer to the supplier. A technical problem exists in that payment throughput is limited by the efficiency of transmitting the purchase orders, the number of purchase orders and the number of invoices between buyers, suppliers, and payors. Furthermore, errors may be introduced due to the mostly manual nature of the reconciliation process between systems. In this regard, supplier invoice analysis and reconciliation by traditional manual methods is usually time consuming, demands a relatively large number of user inputs, and may be intolerant of informational faults.

SUMMARY

In various embodiments, systems, methods, and articles of manufacture (collectively, the “system”) for automated supplier invoice reconciliation is disclosed. The system may receive an order confirmation associated with a purchase order (PO) from a supplier system. The system may receive the PO associated with the order confirmation from a buyer system. The system may receive a first invoice associated with the PO and the order confirmation from the supplier system. The system may reconcile between the PO, the first invoice, and the order confirmation. The system may generate a second invoice in response to the reconciling. The system may pass the second invoice to the buyer system.

In various embodiments, the system may consume an order confirmation message and record the order confirmation to an order confirmation table. The system may post the order confirmation message to an order confirmation API of the buyer system and receive a buyer order confirmation response message. The system may update a status of the order confirmation based on the buyer order confirmation response message. The system may resend the order confirmation message to the order confirmation API in response to an error.

In various embodiments, the system may compare the first invoice against a plurality of invoices in a first invoice table to determine a new invoice. The system may write the first invoice to the invoice table in response determining the new invoice. The system may fetch or receive the PO and the order confirmation. The system may match the invoice, the PO, and the order confirmation. In various embodiments, the system may read a plurality of line items from each of the first invoice, the PO, and the order confirmation. The system may determine a matched line item set comprising a same set of line items across each of the first invoice, the PO, and the order confirmation based on a common attribute. The system may calculate a running total for the matched line item set based on an item price and an item quantity.

In various embodiments, the system may fetch the first invoice from the first invoice table. The system may generate the second invoice based on the PO, the first invoice, and the running total. The system may pass the second invoice to an electronic invoicing API of the buyer system and may receive a reply. The system may update a status of the second invoice recorded in a second invoice table based on the reply. In various embodiments, the system may generate a generate payment instruction file (PIF) message. The system may generate an JSON PIF based on the first invoice and the PO in response to the generated PIF message. The system may pass the JSON PIF to a payment API of the system and may receive a payment confirmation ID in response. The system may associate at least one of the payment confirmation ID or the JSON PIF with the second invoice.

The foregoing features and elements may be combined in various combinations without exclusivity, unless expressly indicated herein otherwise. These features and elements as well as the operation of the disclosed embodiments will become more apparent in light of the following description and accompanying drawings.

