Automating the Request to Pay Process

Automating the Request to Pay Process 150 150 Tim Robertson

request to pay

 

Many of our customers struggle with their purchasing process.

This is because even though there are many stakeholders in the purchase cycle, actual responsibility and accountability can often be muddled.

This isn’t because the different roles in the organization are incompetent or at fault, but that in every organization and industry there is a real lack of transparency throughout various business processes. This is especially true in organizations that opt to use inefficient paper-based processes or when the company’s ERP is not capable of the flexibility required to support efficient workflows*

Whatever the case, organizations are looking to optimize the purchase process with a positive ROI and Request-to-Pay automation may be a great way to do just that.

The Request to Pay Process

With Request-to-Pay automation, everyone with a stake in the purchase is involved in the process, and the process is visible to everyone who plays a role. This high level of visibility actually supports accountability across all roles. Authorized stakeholders can actually see all relevant activity – changes made, when they took place and who made them.

Everyone from the person who makes the requests, to the approver who manages the budget, to the purchaser who makes the purchase, to the person who receives the goods, and to the accounts payable person who ensures payment – are part of the request to pay workflow.

This is what the automated Request to Pay looks like:
  1. The requester completes a purchase requisition, and it is automatically routed for approval.
  2. Once approved the system changes the requisition to a Purchase Order.
  3. The approved PO is sent to the buyer who can now place the order.
  4. Delivery of the product or service is made, and the goods or service receipt is recorded in the system.
  5. The vendor sends an invoice for the product or service, and the system automatically matches the invoice to the PO and the goods receipt.
  6. If there is an exception, it is automatically routed to the proper role for review and exception handling. The exception is in a complete information “packet” that holds an invoice image, the PO, the goods receipt, and notes.
  7. If there is no exception, the invoice is automatically sent to the ERP for payment.
  8. The vendor receives a payment and all of the payment details are recorded in the ERP.

Find out more about Request to Pay automation here.

*Most ERPs have rigid approval workflows, but not by design! (see “Invoice Approval Workflow Gets Flexible!“)