When it comes to transactions between trading partners, many use two-or three-way document matching. That means the invoice, purchase order, and the receiving report or order receipt all contain identical facts about the goods and services that were exchanged. A confirmed match gives the accounts payable team the green light to make a payment to a supplier.
The process virtually guarantees that all required records have been created and received, and allows buyers and sellers to focus on faulty documents and exceptions. In turn, buying organizations avoid overpayments, duplicate payments, and paying before items are received.
In many scenarios, such as when a high volume of expensive items are ordered, additional documents are shared between a buyer and supplier. The documents represent things like obligations and confirmations.
With Tradeshift Pay, you can compare multiple types of purchasing documents – up to seven – to ensure that buyers and suppliers are aligned to the hilt in terms of orders, deliveries, and invoices.
Below is a simple procure-to-pay scenario between a buyer and a supplier to illustrate a 7-way match. Of course, a real-life example would include several documents of the same type, as well as a lot of status updates. And some of the shipping and goods receipt documents could be created by a Tradeshift app partner(s) or in an external system.
|1||A customer creates a Purchase Order for 125 chairs and sends it to a supplier.|
|2||In the meantime, the customer discovers an additional need and decides to order a total of 155 chairs instead. The result is a Change Order.||The order change will refer to the original purchase order in step 1.|
|3||The supplier acknowledges the order, but can only supply 130 chairs at present, and sends a partial confirmation for that quantity via a PO Acknowledgement.||The order acknowledgment refers to the purchase order in step 1.|
|4||The customer accepts the partial confirmation and decides to change the Purchase Order Change doc back to 130 chairs to reflect the new situation.||The order change will refer to the revised purchase order in step 2.|
|5||The supplier executes the shipment of 130 chairs and sends an Advanced Shipping Notice (ASN) to the customer.||The ASN will refer to the order change in step 4.|
|6||Upon receipt of the chairs, the customer converts the ASN into a Goods Receipt.||The Goods Receipt will refer to the order change in step 4.|
|7||At the next billing run, the supplier will create an invoice for the customer covering the 130 chairs.||The invoice is generated based on information on the ASN and the order.|
|8||Upon receipt of the invoice, the customer compares it with the order and GR data.|
|9||As the invoice matches both the PO, GRN and ASNs, a payment is sent to the supplier. A 3-way match is established between the invoice, order, and GR. (The ASN was used to create the GR.) After the invoice is matched, it is sent to the AP system to schedule a payment.|
|10||The customer also reviews the vendor Contract to ensure it matches the invoice and other documents to ensure that the cost of the chairs and delivery terms are met.|
In the workflow example above, we see at least seven types of supply chain fulfillment and billing documents that can be matched:
- Order change
- Order acknowledgment (response)
- Advanced shipping notice
- Goods receipt
In general, all documents relating to the same transaction are linked through a conversation. The conversation between buyer and seller is key in supporting multiple order changes and matching related documents to each other. These conversations define what we mean by cross-network order collaboration.
Earlier this year, we released Magellan 1, which included an update that made it easier for sellers and buyers to communicate orders, change orders, send advanced shipping notices, and share invoice information. And the great things is that all of this matching can be handled automatically by our open APIs.
What to read next
5 steps to rocking your P2P business case