1. Creating an Invoice

After accountant uploads POD, the system should display a modal with the following options:

• Update load status

  • Dropdown with load statuses (pre-populated to “To be Billed”

  • Button to “Update”

  • This allows the user to update the load status

• Export to Quickbooks Button

  • This allows the user to export the invoice to quickbooks

  • If the customer does not exist, the user should be prompted to create the customer and map to quickbooks (functionality already exists)

  • This should all happen within the modal

• Email Invoice Button

  • This button would open a new tab with the new “Email Invoice” interface that combines all steps into one (see specs in Confluence and Invision).

2. Collecting Payments

The payment collection flow can be significantly optimized by:

1. Allowing the user to log payments for multiple customers at the same time;

2. Automating status changes; and

3. Exporting payments to quickbooks

Prototype on Invision

Current Process for collecting payments:

Optimized Process for collecting payments:

Updates to Mark Payment as received screen

In order to optimize the flow, we will need to modify the Mark Payment as Received screen to add additional data points, and to support accepting payments from multiple customers.

The top portion of the page includes only the “Payment date” as an input.

The “Total Income” at the top represents the sum of all payments amount entered by the user in the data table below.

The data table includes the following columns:

• Customer

• Invoice #

• Invoice Date

• Payment Method (Dropdown)

  • ACH - default option

  • Check

  • Credit Card

• Reference # (input)

• Notes

  • A link that pops up a modal where the user can add a note (see below for UI)

• Invoice Total

• Balance

• Payment Amount (Input, currency)

• Paid in Full (checkbox)

  • When selected, the “Payment Amount” input automatically fills the entire “balance” amount, and becomes disabled so the user cannot modify the amount unless the “Paid in Full” checkbox is unchecked

  • If the user manually enters the full amount of the balance into the “Payment amount” text box, then clicks out of the text box, the “Paid in Full” checkbox should automatically get checked, and the text box should be disabled.

• Export to Quickbooks (checkbox)

  • When checked, the data for that payment should automatically export to quickbooks when the user clicks on the “Apply Payment” button at the top.

  • This should be checked by default for all payments

UI for Payment Notes link

Automation after Payments are applied

After the payments are applied, the load status for each load should be updated as follows:

• For payments where the entire balance was paid:

  • Load status changes to “Paid in Full”;

  • IF the Carrier has already been paid on the load

    • Load status and Truck status updated to “Archived”

• Else

  • Load status changes to “Partial Payment”

For all payments where the “Export to Quickbooks” checkbox was selected, the payment info should be exported to quickbooks.

3. Upload Remittance for Collecting Payments (Home Depot)

Overview

Some customers, like Home Depot, are very large and do a lot of business. When they pay Zuum, they issue a single payment for a large number of loads. When they issue these payments, they send Zuum a PDF document that itemizes each load and the payments that were made for those loads.

Currently, the process for collecting these payments is very time consuming and inefficient.

Prototype of Entire Flow on InVision.

Optimized Process

To optimize this flow, we will add a feature that allows the user to upload the “Remittance.” The system then collects the data from the PDF, which is always the same format, and automates many of the steps that previously required human intervention.

The Remittance File

The “Remittance” file is a file that includes information from the customer about payments that were issued FROM the customer TO Zuum for a series of loads.

These customers often issue one payment for a high volume of loads at a time. The Remittance breaks down the batch payment into an itemized list in a PDF. We will need to pull data from the PDF and map it to our system.

Home Depot

Currently, this feature will focus on Home Depot Remittances. In the future, other large customers may send similar remittances, and we will need to create functionality that will know to read the other remittances.

Here is a home depot remittance. The data is digital, and is usually pulled into a spreadsheet by Zuum’s accountant.

REMITTANCE ADVICE.PDF

The remittance includes a data table with the information that we will use in Zuum to log the payment. The following properties should be mapped to Zuum as follows:

Uploading The Remittance to Zuum

The user flow begins in the “Invoices” section of the application. There should be a new button on the toolbar at the top-right, that says “Upload Remittance”:

When the user clicks this button, a modal appears

The modal allows the user to:

• Upload the remittance file

• Modify the Ref # (this field should be optional so that the user can delete this number altogether if desired )

  • The reference # is the “Document Number” in the remittance file. Please see example highlighted below:

  • 

The modal includes a dropdown for the user to select the customer. This is because each major customer will have their own Remittance file format, and will likely require a separate function to pull the required data.

Once the data is pulled from the invoice, it should be applied to the “Mark Payments as Received” screen, with the data mapped to the appropriate columns. See example below:

By Default:

• The customer should be set to home depot for each line item

• Payment method should be pre-set to ACH

• Reference # should be filled based on what the user input in the “Upload Remittance Modal”

• Balance = Invoice Total - any previous payments applied for that invoice # (if any)

• Payment Amount

  • If Payment Amount = Balance

    • The checkbox for “Paid In Full” should be selected

  • Payment Amount != Balance

    • The checkbox for “Paid in Full” should be unselected

• Export to Quickbooks should be selected by default

When payments have been applied, there should be a modal that lets the user know that the payments were recorded:

Automated Processes

Once all payments have been applied, the following processes should happen:

• Status

  • If a balance is paid in full, the status should change to “Paid in Full”

  • If a balance is partially paid, the status should change to “Partial Payment”

• Quickbooks

  • If the “Export to Quickbooks” box was selected, the payment should be exported to quickbooks as a received payment

Contingencies

In some cases, the “Invoice Number” on the remittance file does not match a load number in Zuum.

When this happens, the user will need to apply these payments to a load in Zuum.

User Flow

This flow begins when after the user uploads the file. If the system identifies Invoice Numbers in the remittance that do not match loads in Zuum, then the user should be taken to the following flow BEFORE going to the “Mark Payments as Received” screen.

Step 1. No Matching Invoices Found

The user is informed that there are no matching invoices found for certain payments in the remittance.

There is a data table with the following columns:

• Remittance Inv. #

  • This is the “Invoice Number” as defined in the remittance”

  • Invoice Date

  • PO# (from remittance)

  • Gross Amount

  • Adjustments

  • Net Amount

  • Total to be Applied

    • This field will change based on what the user inputs below

Below the data table there is a section that says “Apply payment to invoice(s)

• This section allows the user to enter an invoice number, and a corresponding payment amount that should be applied to that invoice.

• There is a link to “add another invoice”

  • This allows the user to add another invoice number and payment amount, if the remittance was made for multiple invoices.

When the user inputs an invoice number:

• The system looks for the invoice #/Load # and lets the user know if there was a match or not

  

• The amount that was entered by the user, is then applied to the “Total to be Applied” column of the data table.

  

• If the user clicks on “Add another invoice”, then another line appears with the same two fields, and the link is pushed down. This way the user can add as many invoice numbers as desired.

• The total “payment amount to be applied” cannot exceed the “Net amount” for a single “Remittance Inv. #”

• 

Once the user has completed the process of matching invoices to a “Remittance Inv #”, the user can click on the “Apply Payment(s)” button, and the entire section for that “Remittance Inv #” gets pushed off the screen, as the invoices are matched in the system.

If there are other Remittance Inv. # that need to be matched to a Zuum invoice, they will be pushed up to the top.

Here is an example where there were 3 Inv. Remittance #s that needed to be matched to invoices in Zuum:

If the user does not wish to match these remittance numbers to invoices in Zuum, then the user can click on the “Skip These Payments” button on the top right.

When the user does this, a modal appears, and tells the user that these payments will not be applied in Zuum:

The user can proceed or go back.

Once the user has completed the invoice matching step, whether by entering matching invoice numbers, or by skipping, the user is taken to the “Mark Payments as Received” screen.

• If the user matched the Invoice Remittance #s to invoices in Zuum,

  • The Invoice Numbers and Payment amount for each invoice, should display as rows in the “Mark Payments as Received” screen.

4. Creating a Bill

Overview

Prototype of the entire workflow.

When Zuum hires a carrier to haul a load, the carrier needs to get paid after the work is complete. Zuum needs to keep track of the money it owes to carriers, and whether the carriers have been paid.

In order to do this, Zuum allows the user to generate a “Bill”, which is a record of money owed to a carrier. “Bills” must also be tracked in Quickbooks, as this is Zuum’s external accounting software.

The current process for creating a “Bill” in Zuum, and exporting the “Bill” to Quickbooks, requires the user to navigate to several sections of the Zuum application, and to do repetitive work in Quickbooks.

To optimize this process, we will introduce a feature that allows the user to perform these steps from one page, while automating steps that do not require user intervention.

Current Process Flowchart

Optimized Process Flowchart

Business Process

In order to get paid, the carrier must submit two things:

1. A signed Proof of Delivery (POD); and

2. An invoice

Generally, the POD is submitted shortly after the driver delivers the load, and the Invoice is sent by the Carrier’s company afterward. Sometimes, the POD and Invoice are submitted at the same time.

Generally, Zuum is responsible for paying the Carrier 30 days after Zuum receives the invoice. For this reason, it is important to keep track of the date the invoice was received and uploaded into Zuum.

Optimized Workflow

In order to optimize the accounting process, we will introduce a new screen where the user can “Create a Bill”. This screen will be a single location from where the user can:

1. Create a bill

2. upload an invoice

3. upload/View a POD

4. set the bill date and due date

5. set the amount due

6. Link a factoring company to the carrier

7. View details of the load

8. View and modify the financials of the load; and

9. Export the bill to quickbooks

Prototype of the entire workflow.

Requirements

The workflow begins in the “Bills” section of the Broker Admin application.

There is a new button in the top-right of the tool bar at the top of the page, called “+ New Bill”.

When the user clicks on this button, the user is taken to the new “Create Bill” page.

The “Create Bill” page has the following elements:

“Discard” button in the toolbar

• This discards the “New Bill” without saving any of the information the user inputs, if any.

  • If clicked, there should be a modal that confirms whether the user really wants to discard and lose all changes.

    • 

Enter Load # - Input with search button

Here, the user enters the load number.

• Once it is entered, the system should search for a matching load.

  • If a match is found,

    • the system should display a green checkmark letting the user know that a match was found

    • If there were more than one carriers assigned to the matching load,

      • The user should be presented with a list of the carriers that were assigned to that load

        

      • The user can select the desired carrier to associate with the bill that is being created

      • When the user selects a carrier, the screen should animate into the next state

        • The unselected carriers disappear

        • The selected carrier animates up into the “Carrier Info” spot (see below)

        • The fields populate below

        • The data populates into the sections on the right

    • The system should automatically display and populate the following:

    • 

      • Carrier Info

        • Below the load # input field, the carrier’s basic information should be displayed:

          • Carrier Name

          • Address

          • Phone

      • Invoice Date - with the current date

      • Payment Due - according to the “Expense Total”, which is located in the financials section for that Load #;

        • This should be in US currency format/type

      • The Load details on the right side of the screen (explained in more detail below);

      • The Load Financials

        • This is like an iFrame that loads the financials page of the load. The user should have full functionality of the financial page

          • The only button that I left out of this design is the “view invoice” button under “Expense Items.” This is because the user will be uploading the invoice while creating a bill.

      • If the carrier is linked to a Factoring Company, the Factoring Company “Link” UI should auto-populate with the Factoring Company Name.

        • Else, the “Link a factoring company” combo-box should appear, with the “Link a factoring company” flow. (see prototype).

  • If a match is not found, the system should display a red X next to the Load Input field, and let the user know that a match was not found

• A matching load must be found in order to create the bill

Upload Invoice Button

• This button should trigger an upload modal, with the file type pre-selected as “Carrier Invoice”

• This is the same modal that appears in the Docs & Images section of loads

  • The user cannot change the document type in this setting

  • There should be no “document sharing options” at the bottom

    

• Once uploaded, the Carrier Invoice document should be stored in that load’s Docs & Images section, along with the regular document data (type, description, upload source, etc.)

• After the file is uploaded, the upload button should change to reflect that a file has been uploaded.

  • The uploaded state includes a link to “View” the invoice, and button (“X”) that discards the uploaded file, and brings back the upload button.

    

  • When the user clicks “View”, there should be a lightbox where the user can view the invoice, along with the invoice options. This functionality currently exists in Zuum Fleet Manager (Carrier TMS) when a user views a document.

  • 

    Note: The document title, date, and source should reflect the actual data (in this example, instead of “Blind Bill of Lading” it should say “Carrier Invoice”

  • Below the “Upload Invoice” button there should be a text input called

    • “Carrier Invoice #”

      • The user enters the number of the carrier invoice

      • this becomes a property of the Bill that is being created

• Link a Factoring Company

  • As detailed above,

    • If the carrier is linked to a factoring company:

      • The Factoring Company Name should auto-populate with the Factoring Company Name from the carrier’s details.

    • If the user wants to link a carrier to a factoring company, the user can do this through the “linking a factoring company” flow. (Prototype).

• Export to Quickbooks Checkbox

  • If the tenant account does not have Quickbooks integration enabled, the checkbox should be disabled, with a tooltip that says “To enable this feature, please connect Quickbooks in your account settings”

  • This should be checked by default

  • When checked

    • When the user finishes creating the bill, the bill should export to quickbooks.

    • This is the same functionality as when the user clicks on the 3 dots in the bills section, and clicks “Export to Quickbooks,” except the user is not taken to a separate page to confirm the export.

    • 

    • If the Carrier (Vendor) is not mapped to quickbooks, then quickbooks should automatically create a new record for that carrier and map it to that carrier in Zuum.

Here is the completed state for this page:

Load Details & Financials

On the right side of the screen, there is an area that displays the load details and the load financials.

In the initial state, this area does not display any information.

When the user enters a load number and initiates the search, this area displays the following details from the load:

• Pickup 1

  • City, ST

  • Date/Time

• Dropoff 1

  • City, ST

  • Date/Time

• Commodity Info

  • Truck Type

  • Load Type

  • Commodity

  • Weight

  • Distance

  • Rate Per Mile (US Currency)

This allows the user to quickly check if the correct Load was found.

Load Details Section Heading

The load details section has a heading that says “Load Details.”

When the user enters a load number and initiates the search, the top right of the section heading should display a link with the Load ID# that allows the user to open that load in a new tab.

• This will take the user into the shipment details page of the load #.

The Load Details header also displays the POD status.

• This should mirror the POD status from the load’s Docs & Images section

  • If a POD has not yet been uploaded, there should be a link next to the status that allows the user to upload the POD

    • When the user does this, the Upload POD modal should pop up, just as in Docs & Images, and the user goes through the same flow.

• IF a POD has already been uploaded to the Docs & Images of the load that the user is creating a bill for,

  • The link should say “View”

    • When clicked, this should open, in a new tab, the “View POD” page in docs & images of that load

Create Bill Button

At the bottom of the page there is a “Create Bill” button. This button is initially disabled.

The button only becomes enabled after the user has:

• Looked up a matching load number

• Completed all input fields

• Uploaded a file for the invoice

Once this process is complete, and the user clicks “Create Bill,” the bill is created and the user is taken back to the Bills page.

• There should be a snackbar on the bottom left, giving the user feedback that the bill was successfully created:

Automations

When the bill is created, the following things should happen automatically:

• The uploaded invoice is saved to the Docs & Images section of that load

• Truck status for that load is updated to “Carrier Invoice Received”

• Confirmation email is sent to the Carrier who submitted the invoice (this template should already exist, if not, please let Matan Darey know)

• The Bill is exported to quickbooks (if the checkbox was selected)

Bill Numbering

Bill Numbering

Bill # should be the load number with the following additional elements:

• There should be a lowercase “p” immediately at the end of the load #. The “p” stands for Payable, as this is a bill

• An uppercase letter should be added after the “p”

  • This letter should be the letter “A”

  • If the user creates a second bill for the same load, this letter should be “B”

  • For every additional Bill, the replace “B” with the next letter in the alphabet

  • If the end of the alphabet is reached, add a second letter and continue with the same sequence (ex. Z, AA, AB, AC, etc.)

• Example: A shipment has the Load ID: 1234

  • When the user creates a bill, the bill # should be 1234pA

  • If the user creates a second bill for the same load, the second bill’s # should be 1234pB

5. Bills Module

Prototype

The Bills Module is where the user accountant manages Accounts Payable (money that is owed to carriers). This entire module has been updated to streamline the process of:

• logging payments in Zuum,

• processing these payments through Zuum’s bank, and

• exporting these records into Accounting Software (in this case, Quickbooks).

Payment Processing Requirements

This process of issuing payments requires an integration to a payment processor. In this case, Zuum needs to integrate with its bank through an API. The below flow reflects the Payment Processing Requirements:

Overview

The Bills module has 3 sections:

1. Bills

2. Payments Schedule

3. Remittances

All three sections have the following common elements at the top of the page:

1. Bills Subheader

This is the subheader that says the name of the module “Bills”, and has a button on the right to create a new bill.

2. Tab Subheader

This allows the user to navigate between the 3 sections:

• Bills

• Payments Schedule

• Remittances

Payees

An important update to the bills module is the introduction of the “Payee” property.

A Payee is the person who receives payment for a bill.

Every bill must have a Payee.

In general, the Payee is the company (the carrier) who was hired for the load.

• IF the carrier is linked to a Factoring Company, then the linked Factoring Company is the Payee for any Bill where that carrier was hired for the load.

In the current version of the Bills section, there is a column called “Paid To”. But as you can see below, this column is blank when there is no Factoring Company associated with the Carrier.

In this update, instead of the “Paid To” section, all Bills must have a Payee.

Section 1. Bills

The Bills section is where the user can view all of the company’s Bills that are owed to Carriers who have been hired by the company.

This section consists of the following Elements:

“Export XLS” button in the subheader at the top

When the user clicks on this button, it should export to an excel spreadsheet (Not CSV per Ali’s request), a list of all of the bills that meet the criteria of the active filters on the page.

The spreadsheet should have the following columns:

• Company Name

• Payee

• Bill #

• Balance Due

• Due Date

• Status

• Remittance

• Load #

• Invoice Date

• Balance on QB

• Carrier Invoice #

Filters Menu

The Filters Menu enables the user to display a list of bills meeting a specific criteria. The following filters are available:

• Status (dropdown)

  • All

  • Not Paid

  • Scheduled

  • Paid

  • On Hold

  • Canceled

Status Colors: Spec

• Payment Due Date (Date Selector)

  • Should allow the user to select a date range

  • Should display only bills where the “Due Date” falls within the specified date range

• Search Load ID

  • Enables the user to run a numeric search that only searches for the Load ID property

• Search

  • A free text search similar to the search functionality in the Shipments module

On the left there are Quick Filters that, when selected, automatically set the “Status” and “Payment Due Date” filters. To the right of the Quick Filters are the number of Bills that fall within those filter parameters.

Quick Filter Configuration:

At the top right of this menu there is a toggle that enables the user to group the Bills list by Payee, or to turn this off in order to view the bills individually.

Bills List (Grouped by Payee)

The Bills list is a list of all Bills. When “Grouped by Payee”, the list will consist of two levels:

Level One - Payee

On Level One, each row represents a Payee. The Columns include

• Payee Name

• Total Due

  • This represents the sum of the payments due to that Payee for the specified date range

Level One rows are collapsed by default, but can be expanded when the user clicks on the dropdown button on the left of the row.

When expanded, the row displays a data table that contains a list of each bill that is due to that payee. The sub-data table includes the following columns:

• Company Name (the carrier that was hired for the load)

• Bill #

• Balance Due

• Due Date

• Status

• Remittance # - The remittance # is issued after a bill is paid. Unpaid bills will never had a remittance #

• Load #

• Invoice Date

• Balance on QB - This represents the current amount due on this Bill in Quickbooks

  • If this number is different from the “Balance Due” according to Zuum, the number should display in red.

• Carrier Invoice - This should pop up the carrier’s

  invoice in a lightbox.

Bills List (Not Grouped by Payee)

When the Bills List is not grouped by Payee, each bill is listed individually. The columns on this list are the same, except there is not a “Payee” column right after the “Company Name” column.

Bill Options

Each Bill row has an action button with the following options:

• Place Hold - Changes the bill status to “On Hold”

  • This disables the checkbox that is all the way on the left of the row of that bill.

  • When a bill is “On Hold”, and the user clicks on the “Bill Options”, then this option will say “Remove Hold”, and the bill will return to its original status.

• Edit Bill (opens in new tab)

• View in Scheduler (goes to that bill in the Scheduler)

• Sync Quickbooks - Overwrites the data in quickbooks associated with this bill, with the current data in Zuum

• Void Bill - Changes the status of the bill to “Canceled,” and makes it so that the dollar amount on the bill is no longer due to the Payee.

Selecting Bills

To the left of each Bill row, there is a checkbox.

• When grouped by Payee, each sub-data-table has a checkbox in the header, to allow the user to select all bills within that group.

• When not grouped by Payee, the data table has a checkbox in the header that allows the user to select all bills within that group.

A user selects one or more bills in order to issue payments for those bills. When a user selects one or more bills, the selections are reflected in the “Issue Payments Menu”

Issue Payments Menu

The Issue Payments menu allow the user to schedule payments for bills that are due. This menu has the following elements:

• Bank Link Signifier

  • On the top right there is a blue rectangle with a link icon inside of it, and the name of the user’s bank, along with the last four digits of the linked bank account number.

  • This represents that there is an active link between the application and the user’s bank account

• Bills Selected

  • This shows the number of bills that have been selected by the user in the Bills list

• Total Payments

  • This represents the total number of Payees that are included within all of the bills that are selected

  • Example the user selects the following bills:

    • Payee

      • Mike’s Trucking

        • Bill #1 = $100 (for Mike’s Trucking)

      • Happy Factoring Company

        • Bill #1 = $100 (For Dave’s Trucking)

        • Bill #2 = $100 (For Steve’s Trucking)

    • Bills Selected = 3

    • Total Payments = 2 (because there is one Payee for these two bills, they will be combined into one payment)

• Total Expense

  • This is the sum of the “Amount Due” from all of the selected bills

• Payment Date (date selector)

  • This is a dropdown that allows the user to select a date for when the selected bills should be paid

• Schedule Payments (button)

  • This is a button that schedules the payments for the selected bills

  • When clicked, the status of all selected bills will change to “Scheduled”

  • The payment data should be exported to quickbooks for all selected bills

  • All of the selected bills will be unselected

  • The Bills list should be updated to only show the correct bills (depending on the filter)

  • There should be a snackbar on the bottom left that tells the user ““Payments Successfully Scheduled”

• Effect:

  • The bills are grouped into payees, and the amount of the bills are added up for each Payee. In other words, each Payee will be issued a payment that is equal to the sum of all of the bills that were scheduled for that date.

  • Scheduling these payments, means that the system sets the date as a trigger for a function that automates a payment through the user’s bank, to the payee, on the desired date.

Quickbooks Integration

When Bills are scheduled to be paid, the payment data should sync to Quickbooks, including the date of payment.

Mapping

If a bill cannot be exported because the vendor/carrier is not “mapped” to quickbooks, then the system should automatically map the vendor to quickbooks without requiring user action.

Errors

If a bill payment could not be synced to quickbooks, then an error should appear at the top of the page. (Prototype)

When the user clicks on the “details button”, a dropdown appears with a data table showing the bills that could not be synced.

If there is an action that the user can take in order to fix the problem, that action should be included within the Bill’s row in the data table.

Edit Bill

If a user needs to make changes to the details of a bill, the user can click on the Bills Options menu and select “Edit Bill”

This will open the “Edit Bill” page in a new tab.

The “Edit Bill” page is almost identical to the “Create Bill” page from Step 4 with a few minor differences:

1. The page is called “Edit Bill”

2. The data from the bill is already pre-filled

3. At the top left, the Bill # is displayed

   1. the user cannot enter or change the load number

4. At the top right there is a button to “Void Bill”

   1. This changes the bill’s status to “Canceled”

5. The button at the bottom is called “Updated Bill”

   1. it is disabled until changes are made

   2. Note: Changes made to the load financials should trigger the update bill button to activate

      1. The changes should export to quickbooks if the checkbox is selected

6. Since this is open in a new tab, when the user “Updates” or “Voids” the bill, the user should be taken back to the main “Bills” page

Section 2. Payments Schedule

Prototype

The Payments Schedule allows the user to view and manage payments that are scheduled by navigating to a specific date.

This module has the following sections:

Date Picker (top left)

The date picker allows the user to select a date.

• The current date has blue text

• The selected date has a blue circle around it, and has white text

• All dates prior to the current date are disabled (gray text)

• All dates that are after the current date AND that are not selected have black text

When the user selects a date

• That date displays on the Payments List

• All payments scheduled for that date appear on the Payments List

Payments List (right)

The Payments list is a data table that displays all of the payments that are scheduled on a specific date. The Payments list has two components:

1. Header

2. Data Table

Payments List Header

The Header consists of the following elements:

• Selected Date

• Number of payments scheduled

Payments List Data Table

The Payments List Data Table is a data table with expandable rows.

The Parent rows have the following columns:

• Checkbox

  • Selects the payment

• Payee

  • Displays the name of the Payee, the company that will receive money

• Method

  • Displays the payment method

    • ACH

    • Check

  • There are two payment methods. The payment methods that are available to each Payee will depend on the data that has been input into the system.

    • If ACH data is available for a payee, then the ACH method will be selected by default; else

    • Check method should be selected by default

      • If Check information is not specified, then the following data should be used

        • Company Name

        • Company Address, City, St, Zip

  • More information about payment methods will be in the Payment Processing Integration section below.

• Amount

  • This is the total amount due to the payee for the scheduled payment

    • This is the sum of all bills that were scheduled for payment for that payee

The Child Rows (when rows are expanded) show each bill that is included in the payment. These rows have the following columns:

• Company Name

• Bill #

• Balance Due

• Due Date

• Load #

• Delete Button

  • This button removes the bill from this scheduled payment

  • If removed, the Status of the bill reverts to “unpaid”

Note: If a bill is scheduled, but then its status is changed to “On Hold,” then it is removed from the payment schedule.

Payment Options (bottom left)

The Payment Options menu allows the user to manage one or more selected payments.

The initial state of this menu reflects that no payments are selected.

When one or more payments are selected, the following options are displayed:

• Payment Date

  • This Shows the date that the payment has been scheduled;

  • When clicked, it opens a date picker that allows the user to select a new date

• Payment Method

  • This Allows the user to select the desired payment method for the selected payment(s)

    • If one or more payments are selected, and only one payment method is available, then the other payment method should be disabled for the selection.

  • Options

    • ACH

    • Check

• Payment Note

  • This allows the user to add a note to the payment. This note will appear on the remittance (see below)

• Cancel Payment

  • This button will cancel the payment and change the status to all of the bills within the payment to “Not Paid”

• Apply Changes

  • Initially disabled

  • Becomes active when a change is made to the options

  • When clicked, this will apply the changes to the selected payments

If a payment is rescheduled or canacled, there should be a snackbar on the bottom left of the screen that gives the user feedback about the action that was taken.

• Rescheduled text = “Payment(s) successfully rescheduled. {Option to Undo}”

• Canceled text = “Payment(s) successfully canceled. {Option to Undo}”

3. Remittances

What is a Remittance?

A Remittance is like a receipt for a payment that was issued to a payee. The remittance includes:

• Information of the Payer (the one making the payment)

• Information of the Payee (the one receiving the payment)

• Information about the Payment

  • Remittance #

  • Reference #

    • If the payment method was ACH, then display the ACH # that is returned from the payment processor

    • If the payment method was Check, then display the Check # that is returned from the payment processor

  • Document Date (the date the remittance was generated)

  • Payment Date (the date the payment was processed)

• An itemized list of each Bill that was included in the payment. For each listed bill, the following info is provided:

  • Invoice #

  • Carrier/Company Name

  • Invoice Date

  • Amount

• The total amount of the payment

UI Spec

How are Remittances Originated?

• When a payment is scheduled, and the date of the payment arrives, the payment is processed.

• After the payment is processed, the payment processor returns a confirmation number.

  • That number is used as a reference number

• At this time Zuum generates a Remittance, which includes the bank’s confirmation number, and the information detailed above.

• The Remittance is then stored in the Remittance List, which is accessed through the Remittance tab of the Bills module.

The Remittances List

Prototype

The Remittances list is a data table that lists all of the remittances that have been generated. It includes the following components:

• Export XLS Button

  • This exports an excel spreadsheet of all remittances displayed on the list (subject to filters)

• Filters

  • Payee (combo-box)

  • Text Search

  • Date Range

    • Filters by “Date Issued”

• Data Table with the following columns

  • Checkbox (allows the user to select one or more remittances) for batch actions

  • Method

    • displays the payment method used to issue the payment for that remittance

      • ACH/Check

  • ACH/Check #

    • This is the ACH/Check number returned from the payment processor.

  • Remittance # (auto-generated by Zuum for each remittance)

  • Date Issued (the date the remittance was issued)

  • Total Payment

  • Email Contact

    • The Payee’s email address where the remittance was sent

  • Buttons

    • Email - allows the user to generate a new email with the remittance document attached

    • Download - downloads the remittance document

    • View - opens a preview of the remittance in a lightbox

Batch Actions

Prototype

When the user selects one or more remittances with the checkbox, the “Batch Actions” component should appear at the bottom, and allow the user to perform one of the following actions to all selected Remittances:

• Download;

• Email; or

• Export

If the user clicks on the “X” button of the Batch Actions component, then all of the Remittances should be unselected.