Invoices, UX Iteration 3

On the whole, this looks good to me. It’s definitely consistent with my expectations for an invoice record and the UI is an improvement over my current ILS.

A few notes/questions:

• What happens if the invoice has lines from multiple POs? The current display is very focused on PO line numbers, but it’s a really common use case for an invoice to span multiple POs. So in the list of invoice lines, we’ll want to see both PO and PO line numbers. And when adding new lines, we’ll need to be able to select a PO and then line.

• How do you put in the price and other info for each line initially? I’m assuming that when you use the “add line” button, you’ll see a screen similar to the edit screen shown in this video. But I just want to make sure that’s correct.

• What happens when you pay the invoice? I would like to see a status display on this screen that tells you whether each line is paid or not and whether the whole invoice is paid or not. It would also be great to see date paid for each line.

• How do you create the whole invoice initially? I’m guessing this is pretty straightforward, but one concern is making sure we can enter invoice numbers manually and have them be alphanumeric. Another is that some vendors (YPB for example) reuse invoice numbers after several years, so the system might need to accommodate duplicate invoice numbers in some way. Our current system does not, so we have add an “a” or something at the end of duplicate numbers. Not super high priority, but something many people might encounter.

I’d like to second Kristen’s comments about needing to add/see the PO number on the invoice as opposed to just the PO line. We don’t create multi-line POs, so for us, many invoices have multiple POs attached.

It would be great if you do enter a duplicate invoice number for the system to provide a warning, so you can reuse the number if needed, but so that you can also avoid accidentally paying an invoice twice.

For data entry, it would be great to have the ability to enter new lines on the invoice quickly, with a minimum of clicking. This has been a major area of workflow slow down in OLE. There are a lot of cases where we need to manually enter a vendor’s invoice, and it can have many lines. Being able to tab through to create a new, enter the PO number, and have the basic information populated from the PO quickly (especially for us, where we only have one line per PO) would be really helpful for quick posting of invoices. Then information, like pricing, can be adjusted as needed.

Excellent questions and our intentions are as follows:

1. These invoices can certainly relate to multiple POs and the “Columns” adjustment allows you to add a column for any field that appears on the POL (Purchase Order Line) record. This would include PO number.

2. You are correct on this one, when you add a new line you can provide all the details seen on the edit screen for that line. Also, the intention is if you add a POL number the system would pull it’s details to speed the process and allow you to adjust them if necessary.

3. Our current model will not show an invoice or it’s associated lines as “Partially Paid” the invoice is either “awaiting payment” or Paid. A POL could have many invoice lines/invoices and thus a PO or POL could be partially paid. I agree we should display the invoice status in the summary and will see that it is included. The invoice line status can be added by the user if desired with the column adjustment feature.

4. Thank you for bringing this up as yes you are able to edit the invoice number as desired and our intention is simply to confirm with the user that they intend to create a duplicate invoice number rather than force them to be unique.

This all sounds good. Thanks, Dennis!

Are there plans to have more than “Awaiting Payment” and “Paid” statuses for Invoices? We have an “Invoice Payment Log” associated with each invoice in Aleph that we refer to frequently as invoices move between different staff, the one most frequently used is the final payment status and date, in particular, but the other information is helpful when trying to track things down. I’ve included an example screenshot of the kind of information available in the log below. Some of the fields are superfluous (Description, User note, Action date), but the others are useful.

Aleph invoice log1165×320 11 KB

Note that if our current payment system worked as it ideally would with integrations with SAP, there is a place to put the check number in the final payment information, which I would love to be able to see if/when FOLIO integrates with university financial systems. Currently we batch load our invoices to SAP, formerly R3, but they don’t send any information back.

I’d also like to second comments about displaying PO information prominently rather than POL info. I understand that that info can be toggled using the Columns adjustment, but there’s no references to POs anywhere in your demo (including in the editing of the POL screen), so just wanted to make extra sure that that is more prominent

I’d like to add to the comments about the PO/POL. For very good reasons, we create one po for one resource. From looking at the demo I wonder if the focus on POLs could create extra clicks for those who do not want multiple POLs per PO?

I think the UI looks good. Like Virginia I am not certain that the “payment” statuses are adequate. Part of that depends on whether we are able to work entirely within FOLIO from invoice creation to confirmation of payment and reconciliation of payments, or whether we continue to have the data sent out to another app where we perform the reviews and authorization for a payment. Currently we have the following statuses that support a different part of the workflow. The beginning steps are in OLE, but the later steps are all handled via a local app that sends correctly configured data to accounts payable (which automatically triggers a payment for 95% of our transactions).

In OLE:

1. Invoice creation (EDI or manual);
2. Finalization of invoice (could happen as part of step 1 if the invoice is manually created);

In App (the app updates throughout the day from OLE):

3. Unreviewed (this is first stage of an invoice brought in from OLE–the status in OLE is Final);
4. Reviewed (someone (not the same person who received the material or entered the invoice in OLE) has confirmed the AP vendor number and all of the invoice details (amount, invoice number, etc.)–some skip this step (see Completed or Canceled steps below);
5. Approved (the authorized signor has approved the invoice for payment);
6. Exported (the file for university accounts payable has been created and submitted for automatic processing);
7. Completed (AP returns a check number which is stored; some transactions are not submitted to AP at all (invoices that need to be submitted manually to AP or invoices being charged to a deposit account or housekeeping transactions such as corrections for wire transfers in foreign currency or bank charges);
8. Canceled (Any transaction that is being canceled–when someone accidentally enters the same invoice twice, for example, or there is an error in the invoice)

And a final step that currently happens in MSAccess is the reconciliation of the transactions in the ledgers with the OLE transactions.

Were we able to use FOLIO for the entire process, I can see collapsing 2 and 3 into unreviewed (or some variation of that), but still see a need for the remaining invoice statuses.

I am also still not certain how FOLIO could help with those transactions that we submit manually (primarily wire transfers in foreign currency where we don’t know the exact exchange rate when submitting for payment). Currently we create a second invoice document that has entries for any difference between the projected exchange rate and the actual rate used by the bank.

Here’s how the app currently displays the details for completed invoices:

voucher sample 201801113451×347 28.8 KB

When an invoice is in a foreign currency does the exchange rate display–or can you see it quickly within the invoice? There are many instances where we are using a fixed exchange rate that is not the current day’s rate. I didn’t see a place to manually override the default exchange rate.

Scott makes a good point about the exchange rate. Often when we make payments by wire the amount actually paid will differ from the amount calculated in our ILS - either when the invoice is added or marked as paid - because the payment is made on a different day and the exchange rate has changed. We’ll need to be able to make manual changes to those amounts that aren’t based on the current exchange rate used in the system.

On the topic of duplicate invoice numbers, Deb Fields, who handles all invoice processing in my department, notes that it is very important for there to be a clear system alert when a duplicate invoice is input in order to ensure that they are not accidentally paid twice. We’ll want to make sure there is some way to report on duplicate invoices from EDI loads in cases where we get an invoice both through EDI and mail (email or snail mail), which does happen occasionally.

Thanks to everyone for the comments on PO and POL. For the folks who are saying that the PO is critical, I’d like to explore that further. The POL will be a unique ID number and will be the invoice matchpoint, similar to the Innovative .o number or the Voyager VLI. The POL will not just be 001, 002, 003, etc. Some libraries may choose to create single line POs (one PO/one POL) and others may choose to create multi-line POs (one PO/multiple POLs). As noted, an invoice may include titles from multiple POs, and the proper match between an invoice line and a title will be achieved via the POL.

Will it be important to be able to search for orders by both PO and POL? Will it be important to show both PO and POL on invoices? In cases where an invoice covers multiple POs, will it be important to include both the PO and POL for each invoice line, or just one or the other?

Let’s plan to discuss invoice statuses, based on the feedback from Virginia and Scott. I think it’s safe to assume that some portion of the payment workflow may be happening in a financial system external from FOLIO, and that FOLIO will need to communicate with that system.

Good question about foreign currencies. You’ll be able to toggle between the invoice currency and your system default currency. I’m not sure about manually overriding the default exchange rate.

Re: exchange rates:

In addition to the fixed rate, the date the invoice is added, and the date it’s marked as paid - at Cornell, what Tech Services has been instructed to do is look up the exchange rate for the Invoice Date that’s explicitly written on the invoice.

I wonder if it would help to have a setting that the appropriate admin could enable - “use fixed rate” + enter the fixed rate, vs. “use invoice date”, vs. “use payment date”, etc.?

Regarding exchange rates, you will be able to make adjustments to “payments” (Which are referred to as transactions) after they have been created. The exchange rate used to calculate encumbrances would be based on the order date, the final exchange rate will be reflective of the payment date. When you process an invoice in FOLIO, the system will generate a payment(s). This is not set in stone and it would certainly be possible to allow you to set preferences that tell the system to use the invoice date instead of the payment date. Good idea to add this as a conversation topic for an upcoming SIG meeting.

@Heather: if the invoice quotes the price in USD in addition to the original currency, do you still have to look up the exchange rate? Or is that practice only for invoices that only have non-USD currency?

@Ann-Marie: I asked our invoicing specialist, and she says that if an invoice quotes a USD price too, we use the USD price as per the invoice. So getting the conversion rate based on the invoice date is indeed only for invoices that only have non-USD currency.