0:05 — Setup: pre-approved invoices — The presenter introduces a set of invoices that already went through invoice approval the prior week, were approved by managers, and were pushed into the affiliated ERP as approved invoices. Those invoices have now come back into PaperSave to be considered for payment approval. 0:37 — Why payment approval is a separate workflow — The payment workflow is described as an appendage to the existing invoice workflow because the team approving payment usually is not the team that approved the invoice. The example given is an IT team approving phones from a wireless vendor and tablets for the network, while a different team authorizes the actual payment to that vendor. 1:50 — AP team submits for payment approval — The AP team sees an option to submit an invoice for payment approval or decline it — for instance if it will be paid in-house or was settled another way. The team double-checks that the invoice was genuinely approved and documented in Financial Edge before pushing it forward, alongside other examples such as office supplies and retirement catering. 2:02 — Routing and approver notifications — Where invoices go next depends on how workflows and payment terms are configured; in this demonstration all items routed to the same approver. Notifications arrive the same way as other PaperSave notifications, including email in bulk or individually, and through the mobile application. 2:46 — Payment approver view and fields — The approver opens an invoice, reviews the information, and can approve it to be paid. Visible fields include method of payment, due date, preferred payment terms, how it is paid, when the payment was created, payment amount, and payment status, all configured per customer and updated in real time. 3:23 — Demo environment and batch approval — The presenter notes this is a demonstration environment, so no real payments go to real vendors and the examples are set up as check payments. A common approver pattern is described: reviewing on a set day such as Friday or the 10th of the month, opening a few items, approving, and pushing them out at once. 4:04 — Multi-level approval and the $5,000 escalation — Payment workflows can have multiple approval layers and alternate routings, for example above a dollar threshold or for particular vendors. On submission, two payments went out for submission to Financial Edge as the connected ERP, while a larger one triggered a rule for amounts over $5,000 and escalated to that approver's manager. 5:12 — Payment statuses by payment method — Status fields differ by payment type: ACH and the premium ACH option move through payment accepted, payment processed, awaiting funding, and credit release pending; virtual card is similar with its own statuses; a check moves from check to processing while waiting on postal delivery. 6:06 — Reporting and visibility on payments — The status fields are exportable and reportable within PaperSave. Users can sort by payments currently due, click through to make payments and approvals, and see where funds and payments stand inside the same application. 6:34 — Dashboards in development — A dashboarding tool that will sit inside PaperSave is being built, with example screenshots shown. It is intended to display payments due, payments past due, potentially available rebates, year-to-date spend, and the split of vendors paid by ACH, credit card, or check. 7:57 — New vendor payment-type checks and rebates — When a customer brings on a new vendor and begins paying them, the payments team checks which payment types that vendor accepts and petitions vendors on the customer's behalf. The goal is converting vendors into accepted suppliers so the customer earns more rebates. 8:23 — Activation, onboarding effort, and training — Activation starts with the customer's account manager, followed by onboarding forms for payments expected to take about a two-hour commitment from the customer's team. Most of the configuration work is handled by the vendor's team, and training typically takes about an hour and can be cascaded to staff, which the presenter attributes to the workflow feeling familiar to existing PaperSave users.

Home / Resources / Webinars

Demo: Payments Workflow to Pay Invoices Directly from Your ERP

Key takeaways

Payment approval runs as a separate workflow that attaches to the existing invoice approval workflow, because the team approving a payment is usually not the team that approved the invoice.
Invoices that were already approved and pushed to the ERP come back into PaperSave for an AP-team decision on whether to submit them for payment approval.
Payment approvers see added fields such as payment method, due date, preferred payment terms, when the payment was created, payment amount, and payment status, which update in real time.
Payment approval routing can be layered — a demonstrated trigger escalated an invoice over $5,000 to the approver's manager while the other payments went out to the connected ERP (Financial Edge).
Payment statuses differ by method: ACH-type payments move through accepted, processed, awaiting funding, and credit release pending, while checks move from check to processing while waiting on postal delivery.
A dashboarding tool inside PaperSave is under development, intended to show payments due, past due, potential rebates, and year-to-date spend by payment type.
Activation starts with your account manager: roughly two hours of onboarding paperwork, most configuration handled by the vendor's team, and about an hour of training that can be cascaded to staff.

Overview

This session is a product demonstration of a payments approval workflow that lets an organization approve and issue vendor payments from within PaperSave, connected directly to the ERP. The presenter starts from a set of invoices that had already moved through the standard invoice approval process the previous week, been approved by managers, and been pushed into the affiliated ERP as approved invoices. Those invoices then return into PaperSave with a second question attached: should this now be approved for payment? The presenter frames the payment workflow as an appendage to the existing invoice workflow rather than a replacement, because the group responsible for authorizing money leaving the organization is typically not the same group that approved the underlying purchase — an IT team may approve phones and tablets bought for the network, but a different team authorizes the payment to that vendor.

The first step belongs to the AP team, which sees an explicit option to submit an invoice for payment approval or not — useful when something is being paid in-house or has already been settled by other means. The AP team verifies that the invoice really was approved and documented in the ERP before pushing it forward. From there, routing depends on how the workflow and payment terms are configured; in the demonstration all items went to a single approver. Notifications reach approvers the same way other PaperSave notifications do, including email in bulk or one at a time, and through the mobile application for organizations already using it.

The payment approver's view includes fields beyond the invoice itself: method of payment, due date, preferred payment terms, how it is paid, when the payment was created, payment amount, and payment status. These are configured per customer and update in real time as payments progress. The presenter notes the demonstration environment does not send real payments to real vendors, so the examples were set up as check payments. A typical approver pattern described is periodic review — on Fridays, or on the 10th of the month — glancing over familiar items, opening a few, then approving and releasing them in a batch. When the approver is the final step, payments are submitted directly out to the ERP, whichever ERP is connected, either in batches or one at a time. Additional approval layers are supported: on approval, two payments went out for submission to Financial Edge, while a larger one hit a configured trigger for amounts over $5,000 and was escalated to that approver's manager.

Payment status tracking varies by payment type. For ACH and the premium ACH option described earlier in the broader session by another presenter, the fields in PaperSave move through payment accepted, payment processed, awaiting funding, and credit release pending. Virtual card behaves similarly with its own set of statuses. A check moves from check to processing, since delivery depends on the US Postal Service. All of these status fields are exportable and reportable inside PaperSave, so users can sort by payments currently due, see where funds and payments stand, and act on approvals in the same environment.

The final portion covers what is coming and what adoption requires. A dashboarding tool that will sit inside PaperSave is in development, with example screenshots shown; it is intended to surface payments due, payments past due, rebates that may be available, and year-to-date spend, along with the breakdown of who is paid by ACH, credit card, or check, which bears on where rebates are being earned. The presenter also notes that when a customer brings on a new vendor and begins paying them, the payments team proactively checks which payment types that vendor accepts and petitions vendors to become accepted suppliers, with the aim of increasing rebates. For activation, the starting point is the customer's account manager. Onboarding forms for payments are expected to take roughly a two-hour commitment from the customer's team; the bulk of configuration is handled by the vendor's team rather than the customer's; and training generally runs about an hour and can be passed down to staff, which the presenter attributes to the workflow being familiar to existing PaperSave users.

Chapters

0:05 — Setup: pre-approved invoices — The presenter introduces a set of invoices that already went through invoice approval the prior week, were approved by managers, and were pushed into the affiliated ERP as approved invoices. Those invoices have now come back into PaperSave to be considered for payment approval.
0:37 — Why payment approval is a separate workflow — The payment workflow is described as an appendage to the existing invoice workflow because the team approving payment usually is not the team that approved the invoice. The example given is an IT team approving phones from a wireless vendor and tablets for the network, while a different team authorizes the actual payment to that vendor.
1:50 — AP team submits for payment approval — The AP team sees an option to submit an invoice for payment approval or decline it — for instance if it will be paid in-house or was settled another way. The team double-checks that the invoice was genuinely approved and documented in Financial Edge before pushing it forward, alongside other examples such as office supplies and retirement catering.
2:02 — Routing and approver notifications — Where invoices go next depends on how workflows and payment terms are configured; in this demonstration all items routed to the same approver. Notifications arrive the same way as other PaperSave notifications, including email in bulk or individually, and through the mobile application.
2:46 — Payment approver view and fields — The approver opens an invoice, reviews the information, and can approve it to be paid. Visible fields include method of payment, due date, preferred payment terms, how it is paid, when the payment was created, payment amount, and payment status, all configured per customer and updated in real time.
3:23 — Demo environment and batch approval — The presenter notes this is a demonstration environment, so no real payments go to real vendors and the examples are set up as check payments. A common approver pattern is described: reviewing on a set day such as Friday or the 10th of the month, opening a few items, approving, and pushing them out at once.
4:04 — Multi-level approval and the $5,000 escalation — Payment workflows can have multiple approval layers and alternate routings, for example above a dollar threshold or for particular vendors. On submission, two payments went out for submission to Financial Edge as the connected ERP, while a larger one triggered a rule for amounts over $5,000 and escalated to that approver's manager.
5:12 — Payment statuses by payment method — Status fields differ by payment type: ACH and the premium ACH option move through payment accepted, payment processed, awaiting funding, and credit release pending; virtual card is similar with its own statuses; a check moves from check to processing while waiting on postal delivery.
6:06 — Reporting and visibility on payments — The status fields are exportable and reportable within PaperSave. Users can sort by payments currently due, click through to make payments and approvals, and see where funds and payments stand inside the same application.
6:34 — Dashboards in development — A dashboarding tool that will sit inside PaperSave is being built, with example screenshots shown. It is intended to display payments due, payments past due, potentially available rebates, year-to-date spend, and the split of vendors paid by ACH, credit card, or check.
7:57 — New vendor payment-type checks and rebates — When a customer brings on a new vendor and begins paying them, the payments team checks which payment types that vendor accepts and petitions vendors on the customer's behalf. The goal is converting vendors into accepted suppliers so the customer earns more rebates.
8:23 — Activation, onboarding effort, and training — Activation starts with the customer's account manager, followed by onboarding forms for payments expected to take about a two-hour commitment from the customer's team. Most of the configuration work is handled by the vendor's team, and training typically takes about an hour and can be cascaded to staff, which the presenter attributes to the workflow feeling familiar to existing PaperSave users.

Questions this webinar answers

Why is payment approval handled as a separate workflow instead of being part of invoice approval?

The group responsible for approving a payment is usually not the same group that approved the invoice. For example, an IT team may approve the purchase of phones from a wireless vendor and tablets for the network, but a different team inside the organization authorizes the actual payment sent to that vendor. The payment workflow is designed as an appendage to the existing invoice approval workflow rather than a replacement for it.

What happens to an invoice before it enters the payment approval workflow?

The invoice first moves through the normal invoice approval process, gets approved by the relevant managers, and is pushed into the connected ERP as an approved invoice. It then comes back into PaperSave with the question of whether it should now be approved for payment. The AP team is the first step and can either submit it for payment approval or decline — for instance if it will be paid in-house or was already settled by other means. AP also verifies that the invoice really was approved and documented in the ERP before pushing it forward.

What information does a payment approver see when reviewing an item?

The approver sees the invoice information along with additional configured fields: the method of payment, when it is due, any preferred payment terms, how it is paid, when the payment was created, the payment amount, and the payment status. These fields are added to the system based on how the customer's setup is configured, and they update in real time as payments move forward.

Can payment approvals require more than one level of sign-off?

Yes. Just as invoice approval workflows can have additional approvers and routings, payment workflows can have their own routings — for example when an amount exceeds a threshold or when the payment is for a particular vendor. In the demonstration, two payments went out for submission to the connected ERP while a larger one hit a configured trigger for amounts over $5,000 and was escalated to that approver's manager.

How do approved payments reach the ERP?

When an approver is the last step in the approval process, that step is connected directly to the ERP and the payments are submitted out from there, regardless of which ERP is connected. Payments can go out in a batch or one at a time depending on what works for the team. In the demonstration, the connected ERP was Financial Edge.

How is payment status tracked for different payment methods?

Statuses vary by payment type and are visible in PaperSave. ACH and the premium ACH option progress through payment accepted, payment processed, awaiting funding, and then credit release pending. Virtual card works very similarly with its own set of statuses. A check moves from check to processing, since delivery depends on the US Postal Service. Once a payment is complete the status changes accordingly, and all of these status fields are exportable and reportable.

Are there dashboards for monitoring payments?

A dashboarding tool that will sit inside PaperSave is under development, and example screenshots of the expected design were shown. The intent is to display payments that are due, payments that are past due, rebates that could be available, and how much has been paid so far in the year, including the breakdown of vendors paid by ACH, credit card, or check so an organization can see where its rebates come from. Customers implementing or considering the payments product were told dashboards are coming.

What is required from a customer's team to activate the payments product?

The first step is to contact your account manager. From there, onboarding forms for payments are the initial task and are expected to require roughly a two-hour time commitment from the customer's team. The majority of the configuration work is handled by the vendor's implementation team rather than the customer's staff. Training typically takes about an hour and can be passed down internally to other staff, which is attributed to the payment workflow behaving natively within PaperSave for existing users.

How are approvers notified that a payment needs review?

Notifications arrive the same way as other PaperSave notifications. That includes email, either in bulk or one item at a time, and organizations already using the mobile application can see pending payment approvals there as well.

Table of Contents

Get A Demo:

Simple solutions. Powerful results. Seamlessly integrated.

Get a PairSoft Demo