No.

At the main page, click on "Select Statement by Department". Type in your area/org and click "Submit".

This is what you bought last month.

The rest of the select criteria default to what we think most customers will look for: last month's documents, regardless if they've cleared CUFS or not, and from all vendors currently feeding the site.

For questions on individual charges, first note which vendor the charge is from (ex: Fleet, Parking, Mailing). Then click on "Contacts", which is at the upper left of all pages. That has a table of departments, along with home page, contact name, phone number, and email.

For questions on the site itself, or with suggestions on how to improve it, contact Chris Ryan (c-ryan@umn.edu, 612-624-6821). Please spend a little time beforehand going over this FAQ to see if your question has already been asked by someone else.

This site may eventually house tens of millions of transactions. We require area to prevent you from accidentally pulling all charges, which would otherwise happen if you clicked "Submit" before entering any select criteria. Our server would handle the request, but your desktop tools might quit after a hundred thousand records.

We recognize however that some central areas, like Audits or the Controller's Office, may have a responsibility to periodically review charges across multiple areas. If you work in one of these areas and need this access for an audit, please contact Chris Ryan for assistance (c-ryan@umn.edu, 612-624-6821). These larger queries would likely need to be done onsite, using our server-side tools.

There are no drop down lists for area/org because those department identifiers change over time. We wanted to make sure that you could type in an area/org even after it's no longer used (and so not available in a current drop-down list), in order to inquire against historical charges

Similarly, historical inquiries also make it hard to include department names next to area/org values. For example, over the last ten years 591-2000 has switched from Support Services to University Services to Auxiliary Services.

You are selecting on the fiscal year and period that these documents were posted to CUFS. That is usually, but not necessarily, the month when you purchased the goods or services. If the documents are not yet posted, you are selecting on the fiscal year and period that they were submitted to post.

This date is shown as calendar month and year, rather than fiscal period and year. We thought the former would be clearer to non-financial customers. We spell out the month name so financial staff will not mistake it for the fiscal period.

The posted flag represents the status of a document at CUFS. Unposted means that the document has not yet been processed, posted means that the document has cleared through CUFS.

Posted documents cannot be changed. If the dollars are wrong on a posted document, you don't fix them, but send through another document to adjust. Information on unposted documents however is subject to change. That's why it's only worth reconciling those documents that have already posted.

By including a select on posted flag, we are attempting to simplify your reconciliation of our charges to CUFS. When you de-select the "Include Unposted" check box, only those charges list out that have posted to CUFS, and so only those that appear on your CUFS general ledger listing (the UA611).

In our initial interviews we learned that some larger departments assign different staff to different vendors. Perhaps you are responsible for mailings in your area, but not vehicle rentals. If so, you might de-select Fleet Services.

The standard format is what you've been receiving from us for years. It has vendor-specific headings.

For example, when you look at fuel transactions, there are columns for fuel type and number of gallons. A loading zone permit has a column for contract. All three columns are not normalized into single column of "what you bought".

The normalized format is a new concept. It abstracts spend across vendors into common columns.

As mentioned in the section "Why are you doing this?", we started out this project by talking to our customers. Many seemed to be normalizing their spend across vendors, creating packets sorted by who made the purchase. The "who" would then be asked to write down the "why".

We also read through the University procedure on inter-departmental charges. A link to that is on the upper left of our main page. The procedure directs internal vendors to establish "who, what, when, where, why". Several customers even quoted this phrase to us, or abbreviated it as "the five W's".

In the end we decided that we could only answer four of the W's: who, what, when, and where. Why a customer purchased something would have to be filled in by them. But we could offer a utility for the customer to type in a "why", and have that fifth W display along with the other four.

Which format gets used will vary by person, and even within a person.

For example, I manage a smaller department at the University, with about a dozen people and annual revenue between one and two million.

For me, the standard format is most useful in spreadsheet. Here I can do analysis like whether one should be purchasing fuel onsite or with a fuel card, or whether it makes more sense to keep renting vehicles or maybe switch to a lease. At least for me, the normalized format puts too much data into spreadsheet cells. A person can total a column for gallons of fuel. But how do you total a column called "what"?

In display and print however, I prefer the normalized format. Regardless of transaction type, the columns are all the same. So it's easier on the eyes as I scan down the pages. Who bought the stuff is always on the far left, followed by what the stuff was.

It's true that a vendor's identity starts to blur in the normalized format. But as a manager, I don't really care about our vendors. I just care about how much of our money they now have, who gave it to them, and what we got in return.

Your preferences will likely be different, tailored to the work that you do at the University.

Yes.

They are the identical transactions (same dollars, CUFS document numbers and so on), and come from the same table.

The spreadsheet button creates a comma delimited file, with an extension of "csv". This is the most generic of spreadsheet formats (unlike say "xls" for Excel, "wk*" for Lotus, and "wb1" for Quattro Pro), and so the most likely to be recognized by whatever spreadsheet software you prefer. So if you can't see the spreadsheet, maybe check these two things first:

1. You might not have any spreadsheet software on your computer. The University has negotiated reduced pricing for Microsoft Office (including the spreadsheet software Excel). But this license is only valid (at least at the time of this writing, January 2005) for computers owned by your employer. That probably does not include your home computer. If you cannot or do not want to use Excel on your computer, there are other spreadsheet packages available. Many of these are "open source", and so low cost or even free. All should read a "csv" file as a spreadsheet.

2. Even if your machine does have spreadsheet software, your computer's operating system or internet browser might not launch the spreadsheet software when opening a document ending in "csv". The default settings should associate "csv" with spreadsheet software, but those settings can be changed. The ideal would be to fix those settings, but you should still be able to view the spreadsheet without doing that. First save the spreadsheet off into a directory, and then launch the spreadsheet software manually. Open up the file you just saved.

And of course if your computer is tied into a University network, please talk to your network administrator before downloading software or changing settings.

You can use the spreadsheet for analysis.

The following are a few quick ideas for Fleet and Parking transactions. Our intent is not to get you to run these specific analyses. Many will not make sense for your department. Instead we're just trying to get you into a mode of thinking where you will come up with your own analyses, ones that will help your department.

1. Many University departments operate 24x7. But perhaps yours does not. If not, you might want to know if parking was getting charged against your account during the evening hours. Those could be charges for personal business, rather than departmental. To check that quickly, maybe sort the budget charge card transactions by transaction time, and look for times greater than 20:00 (8pm).

More than likely any late night parking was legitimate, someone just came in to check on a project or experiment. So maybe you agree in your department to type in a reason why for transactions that could be questioned. That way you save the staff time discussing these things, while also keeping your department free from any hint of impropriety.

2. Are people buying snacks with your fuel card, or paying sales tax when the University is exempt? Sort and subtotal the fuel card transactions by product code.

3. Is it cheaper to buy fuel at our pumps (with a fuel key) or at a private gas station (with a fuel card)? Build a formula over gallons of fuel and dollar amount, and perhaps graph by purchase date to reflect changes in market prices.

4. Is your department working for a cleaner environment? Find out how heavily you're drawing on alternative fuels, like ethanol or natural gas. Sort, subtotal, and maybe direct the results to a pie chart.

5. Should your department be leasing vehicles rather than renting them. This is a little trickier than a simple sort and subtotal. A single leased vehicle will not replace two rented ones, if both are rented during the same time period.

6. Would it be cheaper for your department to purchase a Quarterly Individual Vehicle contract, or should you stick with paying for individual instances of parking. This is similar to a lease vs rent analysis. A contract could replace one budget charge card, but not two that are used on the same days.

7. You held a conference and made parking reservations for the attendees. But many of those people showed up halfway into the first presentation. A formula or two will give you the max, min, and mean times of when people entered the ramp. Use that to adjust your conference literature, to tell people what time they need to arrive.

8. Did you reduce the vehicles that your department leases, but forgot to also reduce the official vehicle permits? Or maybe it's the opposite, since work has picked up and you're now leasing more. Run a count on both blocks of transactions.

That is the default name of the spreadsheet, as generated off the web.

If you save the spreadsheet, you will want to name it something more meaningful. Also the spreadsheet software that you're using may prompt you to save it with its proprietary extension (ex: "xls" for Excel, "wk*" for Lotus). This shouldn't harm anything, and doing so will allow you to use more advanced features in that software.

To keep things simple, there is just one spreadsheet button and one printout button.

If you're using Excel, the software will translate the "csv" into an "xls" for you. You can then select out the columns needed and add in your own formatting.

The amounts are in the middle so that you can total them across transaction type, with just the summary function on the one column. Some transactions have under thirty columns while others have more than forty. Putting the amount at the rightmost column of a transaction would have placed it in different columns based on transaction type, and so prevented that easy summation.

The spreadsheet sorts first by vendor, then vendor transaction type, then by the same sort that the printout, display, and CUFS GL listing do (i.e. CUFS document type, CUFS document number, etc).

There were a few reasons why we sorted first by vendor and vendor transaction type.

The spreadsheet puts data into columns. To be understandable, the columns need headings. People found the spreadsheet distracting when the same headings kept recurring. Sorting first by transaction type allowed us to just write the heading once, at the beginning of that transaction type.

The printout is an Adobe "pdf" document. So if you can't see the printout, maybe check these two things first:

1. You might not have the Adobe Reader product on your computer. This is a free product, shipped on most computers. If the product is not on your computer, it can be downloaded for free from www.adobe.com.

2. Even if you have Adobe Reader, your computer's operating system or internet browser might not launch Adobe when opening a document ending in "pdf". The default settings should associate "pdf" with Adobe, but those settings can be changed. Of course the ideal is to reset those settings. But even without the default settings, you should still be able to view the printout in Adobe Reader. First save the printout off into a directory, and then launch Adobe Reader manually. Open the file you just saved.

If your computer is tied into a University network, please talk to your network administrator before changing its settings or downloading software.

With the printout you can print, navigate, and annotate.

1. Print
Don't print the display. The display cuts off text on the bottom and right, and leaves too much white space on the left. Things are not much improved if you switch from portrait to landscape orientation, or shrink and expand margins.

Don't print the spreadsheet (or at least not until you've selected out the columns and rows you're going to do calculations on). Some transaction types have forty columns. Those won't fit on any page, or at least not in a font size that you could read.

Do print the printout. The printout has page numbering, a table of contents, subtotaling, and coherent page breaking. When you have a long list of transactions, the totals and header information are re-printed at the top of each new page. Most importantly, when you print the printout, everything fits on the page.


2. Navigate
In addition to printing the printout however, you can also navigate through it.

To do this, first generate the printout. That should launch Adobe Reader from within your web browser. Now click on some of the Adobe arrow icons pointing left and right. These will move you to the next page or last page, or back one and back to the beginning. Some other icons look like a piece of paper with a corner folded. Try these out. One shrinks the page so that you can see its layout in your browser. Another widens it to the width of your browser, making the text easier to read. A plus and minus allow you to zoom in and out of text, in case you're working with a smaller monitor.

Perhaps the most useful icon however is the "Find". It looks like a pair of binoculars, and there's a similar "Find Again" icon with binoculars and a curvy arrow over it.

We create each of your printouts as full text indexed. That adds a few seconds onto the generation of your printout. If you're running a hundred page printout, that indexing may add quite a few seconds. Hopefully it's worth the wait however, because that indexing allows you to search through the printout.

Click on the "Find" icon, those little binoculars. A window pops up. Type part of the CUFS document that you want to research. Click the "Find" button and you jump to there. Maybe you don't know what document you're looking for, but are just researching a discrepancy. You could type in the missing dollar amount. Do you want to make sure that a Fleet work order or Parking reservation cleared through CUFS? Search on the work order or reservation number, or even the name of who placed the order.


3. Annotate
After printing the printout and navigating the printout, you may want to move onto the next step--annotating the printout. Some annotations require software from Adobe, the Distiller product in addition to the free Reader product that you're viewing the printout with. The Distiller may already be on your machine. It's inexpensive software, so some U of M network administrators install it as a matter of course.

When you annotate a document, you are making changes to it so that the document is more understandable to your co-workers.

For example, perhaps the simplest annotation is yellow highlighting. You can certainly email the printout to co-workers for review. Rather than email it plain however, you might first highlight the half dozen transactions that you have questions about.

The green underlining could serve a similar purpose.

A little more threatening might be the red strike-out. These could be transactions that you're disputing, or ones that you feel another department should reimburse you for. You could even combine that red strike-out with note. These function like the paper post-it notes that you may now be sticking onto documents.

There is also a stamp tool, with a blue "Draft", a green "Approved", a red "Final", and a green "For Comment". You might find a use for these.

You should know that these annotations only stay with your copy of the printout. We don't store them in our file of transactions, since other staff may want to view the transactions without your annotations. So make sure you save your work.

The printout is in black and white so that customers aren't tempted to print it on a color printer. The total cost of printing in color (not just paper, but also ink cartridge and printer depreciation) can reach $0.50 per page. Printing black and white runs around $0.10 per page. Printing black and white at a centralized printer (like at our copy centers) costs even less, around $0.02 - $0.03 per page.

The printout is devoid of logos, gophers, grid lines, watermarks, and other features in order to leave you plenty of white space for annotation. Most people may use pen and highlighter for this. But you might also want to try the Adobe products, and so save the annotations to your electronic copy.

The printout is in a non-proportional font (Courier), so that letters remain in fixed columns. The hope was to give the clarity of grid lines, without cluttering up the report with the actual lines.

Currently we just email out the standard printout.

We wanted to keep the email sign-up very simple at first. But if there is interest, we could adjust our sign-up to also send out the normalized printout, or allow clients to choose between the two or get both.

Reports are emailed after the soft close of each CUFS month. That means you should get each month's email on the fifth or sixth working day of the following month. The June report might come a little later, since that is the last month of the fiscal year.

We need to wait until after the CUFS soft close in order to download the transactions that posted in that month. We then cross-reference these CUFS transactions against their detail in eStatement, and mark that detail as posted. We also update CUFS data on eStatement detail (ex: area/org, object, amount, month/year posted), in case those were changed on CUFS before posting.

We are adding vendors monthly, and so didn't want people to miss out on the new vendors simply because they didn't update their sign-up.

The spreadsheets are for analysis, and we thought that the analysis would be most productive when done interactively and across multiple months.

Find the CUFS document at the top of the display. Click on the button for "Add Reason Why". Type in your comments. We limit them to 540 characters, but a counter will decrement as you're typing so that you know how much space is left. If you have a very long comment, just finish off the first thought and add a second.

If needed, reference the CUFS line or sequence number in your comment. We initially thought to put comments next to each detail line. That cluttered up the screen however, and made it difficult for people to comment on the entire purchase.

When you are finished typing, click submit. The screen will refresh, and your comment will display along with your x.500 identifier and the date and time you entered the comment. Your comment will have that heading in bold, to make it easy to distinguish from the comments of others.

Don't worry if you made a mistake. A void button appears next to any comment that you have made (whether in this session or a previous one). To remove your comment, click on that void button followed by its confirmation screen. The comment still stays in our files as an audit (just like a voided financial transaction), but does not show up on any reports.

We originally intended to allow this, but none of our test customers thought it was necessary.

Leaving off attachments may have made this communication over purchasing more streamlined. All justifications get typed in, where they are immediately visible when you call up the transaction. You don't have to open up attachments to see why a purchase was made.

Yes. There is no cost effective way for us to track who should or should not be able to comment on a purchase.

However an employee's x.500 identifier is stamped on those comments. This provides the same control over inappropriate comments that exists for inappropriate emails.

Please use clean, professional language when commenting purchases.

If you accidentally type in something inappropriate, just click void to remove it.

We had originally planned to do this, or offer separate options (one for a printout with comments and a second for a printout without comments).

However our initial customer group did not see value in it, and thought multiple print options only made the site more complex.

This was most often articulated as a drill-down from the UM Reports general ledger listing. Clicking on the CUFS document there would bring up the detail from our site.

The thinking here seems to be this.

This site aggregates transactions across vendors, and we encourage vendors to provide as much detail as possible on those transactions. That creates substantial data for analyses.

Currently we only offer a spreadsheet download for this. Customers get the data, but have to write their own analyses.

But perhaps we could take things a step further and build some "business intelligence" into the site.

Say we code several dozen stock analyses into a canned report. After inquiring on a set of transactions, clients could click on a button called "Analyze Spend" or "Save me Money". In theory, this could save dozens of clients from building their own spreadsheets.

But there are also arguments against building in that business intelligence.

Before starting such a report, we'd want to understand if clients are even doing analyses. If so, we'd want to catalog the questions that they are asking. If few are common across areas, then a common report would be less useful.

Also the spending needs of departments can vary widely. Patterns that makes sense for one may not make sense for another. A common report might obscure that, unless it was worded with considerable caveats.

Like many web sites on campus, this one is integrated into the x.500 signon. So if you've already authenticated to look up your place on the parking waiting list or make sure your last paycheck was correct, you shouldn't need to re-authenticate at this site.

But there are other forms of integration that are more tailored to the vendor application. If you bought stationary and business cards, it might be nice to click on the charge to view the Adobe pdf of those items or even re-order more. You might not want to do that with a parking charge, but perhaps you'd like to change the contact name and phone on a permit.

Of course in both cases you could just email the contact with your request, and attach a printout from this site as an attachment. At this point we're not sure if something more refined would really get used.

In addition to putting multiple vendors onto one site, we're also increasing the amount of data for the vendors. So you're not only seeing a charge for a vehicle rental, but also everything we could find about that transaction (ex: vehicle make/model/year, license plate, contact name and number, department, where the car was driven to, the date and time of both arrival and departure). Not all that data may be spelled correctly, especially the new stuff that you're seeing. That should improve over time.

The question of spelling names right however has triggered additional thoughts. If we captured x.500 identifier at order, we could cross-reference it against central demographics. That would get everyone's name spelled right, plus provide a contact phone number and email address.

In addition however that x.500 identifier would also allow us to start offering reporting by individual, rather than just by department and document. That is, you could inquire on your own personal spending with us, regardless of what department it went against. Alternatively your department could request that people who made charges against it get a monthly email, with those charges attached. This is similar to how the purchasing card currently works. Reports are broken out not only by department, but also by individual.

Implementing such a report however would require some extensive process change, across a dozen or two departmental systems. Before making the investment, we'd want to be sure that the reporting would be used.

Currently requests for enhancement are mailed to Chris Ryan (c-ryan@umn.edu). We aggregate them and post summaries here. We could move to a discussion group format, where you could post and respond to each others postings.

The upside is that your thoughts would be articulated exactly as you expressed them. The downside is that issues can get scattered (i.e. the same thoughts expressed one day and then three weeks later, rather than summarized into one posting), and use could drop off after the initial roll-out.

We met with financial staff from our customer departments. They described a process that many of you may be familiar with. Each month they get their UA611 CUFS report, the list of general ledger documents that posted in the previous financial period. Next they start digging for the details behind the expense documents--tracking down paper billings from Parking, making print-screens off the Mailing site for courier trips, downloading a spreadsheet from the U Market site for supplies, and leaving a voicemail at Fleet to see who rented a van. The University has several dozen internal providers, who all report with various tools (paper, web inquiries, both, neither, emails) and at various intervals (weekly, biweekly, monthly, quarterly, annually).

Often our customers are digging for "who"--which employee, not just which department, parked at that ramp or rented that vehicle. That's rarely on any invoice, whether paper, web, or email. Sometimes the "where" will help out (what ramp, which copy center), or maybe the "what" (ethanol or unleaded).

After the digging comes the reporting--drafting up internal spreadsheets or making photocopies. These get used to justify cross-charges, to try and identify who's doing all that excess parking, or maybe just detail out what another mailing might cost. Often this reporting is broken out according to the "who", and distributed to each "who" to verify.

At this point the "who" gets to fill in the "why". Sometimes this is done with an email from the purchaser to the accountant, with a short conversation before and after, and with the process repeated when the accountant's supervisor asks. Other times the "who" writes the "why" down onto the paper bill or web print-screen. The annotated pages are copied and distributed, with the annotations later adjusted or disputed, but maybe not on every copy.

Anyway the whole process seemed to be consuming a good amount of University labor. Indeed for grants we had even built an infrastructure to do this, with Principle Investigators and a department called Sponsored Financial Reporting.

So our group started thinking about how to reduce this labor, to streamline this communication over purchasing. Our experience had been that communication went quickest when centered around a common report. That one common report was worth more than a dozen individualized ones. The trick of course was in designing that one report.

For example, we didn't want just accountants and analysts getting the report, but also managers, auditors, academics, researchers, and our own customer service staff. That meant that the report would have to be very simple to generate, which drove design decisions. So, for example, we decided that there could only be one date to select on, not a choice of order date, ship date, invoice date, and so on. And the date would be the only financial one common across the University--the CUFS posting period. Since this is a month rather than a date, the select would be even easier. An advanced user of the site could still accomplish all that reporting by order date, ship date, invoice date, and whatever. But he or she would have to first direct the output to spreadsheet, and there sort and subtotal by the desired columns.

In the end we decided on nine broad requirements:

1. Make the report easy to access
Serve it off the web, after passing x.500 validation. Even better, put in an email sign-up so that staff could get monthly reports without even visiting the site.

2. Make the report simple enough for anyone to generate
Use very few select criteria, and default them to what most people would want.

3. Allow the charges to take annotation, to communicate why a purchase was made
Do this on a public annotation, so everyone involved with a project or department could see the same information, and clients could reduce the emails and notes that are currently used to justify spending. But keep the annotation controlled, by stamping comments with x.500 identifier and date/time. And of course don't allow dollar amounts or other posted information to be changed.

4. Eliminate the UA611 reconciliation by making the report transparently reconcile to CUFS
Stamp charges with CUFS document numbers and sort by them. Pattern the select criteria after the same select criteria used for CUFS general ledger listings (ex: area/org, object/sub, fiscal period, and posting status).

5. Within the constraints of a central GL listing, provide the cohesion of a vendor invoice
Populate CUFS documents so that detail within logical entities (ex: Fleet work orders, Parking reservations) all come under the same CUFS document line. That way the entity header information (ex: vehicle make/model/year, work order total) doesn't get repeated across different document lines.

6. Make the report detailed enough to answer non-financial questions
Don't just show how much the parking was, but also what time the car entered and exited the ramp. Let people see who signed for a courier order, and when their package showed up.

7. Consolidate the report across vendors
Don't just offer the parking charges, but also the vehicle rental, mailing, catering, and whatever else is out there.

8. Offer the charges in an optional, normalized view
Don't just display charges in the traditional vendor-specific columns (ex: fuel type for Fleet, facility for Parking, pick up time for Courier). But also offer to normalize that spend across vendors, and so reduce the normalizing that customers seem to be doing on their own (i.e. re-entering charges from multiple vendors into spreadsheets, and then sorting by who made the purchases). These normalized columns would be who/what/when/where/why, the "five W's" that clients kept quoting to us, and that are spelled out in U of M procedures on documenting internal charges.

9. Make the report available in multiple formats
Don't offer just a display for quick look-up and print-screens, but also a spreadsheet for analysis, and (perhaps most importantly) a formal printout. The printout should accommodate both those who prefer to read online and offline (i.e. on paper). So, for example, for offline reading create a table of contents with chapter headings by vendor, so people could flip to where they needed to go. But for online reading, full-text index the invoice, so that people could search for document numbers.

This is a recurring question at the University, and perhaps worth addressing in detail. First we'll need to work through some terms.

Invoice--only the first half of a financial event
An invoice lists your charges. Completing the event requires a response from you (ex: payment by mailing in a check).

Sometimes both halves of the event happen right next to each other, so are not always understood as two transactions. But you can still see them both if you slow things down a bit. At the grocery store you're "invoiced" with the cash register slip. Payment happens before you can take the bags of food out to your car.

Statement--a completed financial event
Unlike an invoice, a statement is a list of completed financial events. If you've taken out a house or car loan, each year you may get your monthly payments listed out in a statement. Sometimes these statements list both the charges and their payments, or sometimes only the payments. Nevertheless each month saw two transactions: charge and payment.

Again, you don't need to respond to the events listed in a statement. They have already completed.

Buying and Selling
So far we've only been talking from the view of the buyer (getting charged and paying). That event also triggers two mirror transactions for the seller (charging and getting paid).

The accounting terms for those four transactions reflect that mirroring: receivable and receipt, payable and payment. A sale from the hardware store to you generates a receivable for the hardware store, which is satisfied by the receipt of your cash. That same sale generates a payable for you, which is satisfied by the payment of your cash.

Of course your response to the payable need not be payment. The response might be a complaint (if you disputed the quality of the goods), a return (if you bought the wrong goods), or just nonpayment (if you didn't have any money). This forces the seller to respond to the non-receipt of his or her receivable. The hardware store owner might accept back the goods, write-off the bad debt, assess late fees, or sell the receivable to a collection agency.

Transferring
Not every financial event is buying and selling. Some are purely transfers. Every spring that hardware store owner may move the snow shovels from the display window to the basement. That inventory wasn't purchased into the store or sold out of it, just transferred within. Similarly, pretend that you're one of those people who sets up multiple savings accounts: one for holiday spending, another for vacations, and a third towards savings for a new car. Moving money between these accounts isn't buying or selling. You're just transferring.

Buying, Selling, and Transferring
Two upside down triangles might illustrate this:

Hardware Store          Your Household

Buying   Selling         Buying    Selling

Transferring               Transferring


Draw a line from your Buying to the Hardware Store's Selling, both marked in bold above. That's you getting a new snow shovel.

By now anyone with an accounting degree has started to cringe. That transfer of shovels isn't the single transaction that we've implied so far, but really two (a debit of inventory at the first location followed by credit of inventory at the second). Similarly, when the hardware store owner receives payment, he or she is really processing two transactions (credit to cash, debit to outstanding receivables). Nevertheless, an understanding of double entry accounting really isn't needed to explain the original question--why Home Depot gives you an invoice while U of M Parking sends a statement. So we'll continue to talk as if we practiced single entry accounting, without debits and credits, in order to keep the discussion accessible to a wider audience.

AP, AR, and GL
Remember that the buyer really underwent two transactions at the hardware store (generating a payable when he received the goods, and satisfying that with a payment when he handed over the cash). The seller underwent two mirror transactions (generating a receivable when he handed over the goods, and satisfying it with a receipt when he accepted the cash). Institutions, and even many individuals, write these transactions down. That not only helps them understand where their money is flowing, but also tracks what financial events haven't yet completed (ex: receivables that aren't yet receipted, which is money owed to you). Those institutions are really careful however not to mix up the buying and selling, and so confuse the money owed to them with the money that they owe to others. So they enter their buying transactions into one book, and their selling transactions into a second book.

Accountants call these books ledgers. The book for buying has payables and their payments, and so is referred to as the Payables Ledger. The book for selling has receivables and their receipts, and so is referred to as the Receivables Ledger. Often the word "Account" is prefaced and the word "Ledger" dropped off, giving Accounts Payable and Accounts Receivable. They are abbreviated AP and AR.

There is a third ledger for transfers--moving those snow shovels from the display window into the basement, or switching savings dollars from the holiday account to the vacation account. This is called the General Ledger, abbreviated as GL.

These two upside down triangles would then be equivalent:

Financial Transactions

Buying      Selling

Transferring


Financial Transactions

AP      AR

GL


Once again if you're an accountant, you're probably starting to cringe. Reality is more complex than an upside down triangle. AP and AR transactions are summarized in the GL by account. Indeed sales and purchases are usually done in ledgers further up the tree (Sales Order and Purchase Order), summarized by customer/vendor plus account into AR and AP, and summarized further from there by just account into GL. And although the movement of savings dollars is a pure GL transaction, that movement of shovels would be more elegantly captured by transactions in an Inventory Ledger, which would also summarize by account into the GL.

But this write-up is directed at a non-financial audience, and the above paragraph may have just lost half of them. The key issue here is that buying, selling, and transferring happen in three different ledgers. That's captured in the upside down triangle.

Satisfying internal AP and AR through a shared GL
With this background we can now move onto the original question--why you get an invoice from Home Depot, but a statement from U of M Parking.

Pretend that you and the hardware store owner get along well enough that you decide to form a co-op. A few other local businesses join, along with most of your neighbors. Rather than invoice each other for goods, you'll just email each day's transactions to the local credit union. Since you all bank there, the credit union can execute your internal buying and selling as transfers. Each month the credit union sends you a statement of transfers in and out of your account, and posts a consolidated statement for the entire co-op.

There are great advantages to this, primarily in control, cost, and convenience:

Control
Maybe you were never really very good at writing down your transactions before. If so, this central list could give you a clearer idea of where your money is flowing.

Cost
Much of the overhead of buying and selling has been removed. The hardware store owner doesn't need to worry about collections when selling to fellow co-op members. So he or she can remove that cost out of the pricing to them.

Convenience
Your children can pick up goods from co-op members, without you taking the risk of giving them cash or a blank check.

But along with these advantages comes an opportunity for confusion. Within the co-op, internal AP and AR are now settled through a shared GL. However you may still be keeping your own three books at home, one each for buying (AP), selling (AR), and transferring (GL). After all, whether you buy a snow shovel from the hardware store or from Home Depot, you're still buying. Co-op or no co-op, at the end of either financial event you've got more shovels and less money. So you enter a purchase from either Home Depot or that hardware store into your Accounts Payable Ledger.

But something has changed. Unlike before, getting that snow shovel no longer means drawing a line from your buying to the hardware store's selling. Instead, that line crosses through the co-op's transferring. All three are marked bold below.

The Co-Op

Buying      Selling

Transferring


Hardware Store          Your Household

Buying   Selling         Buying    Selling

Transferring               Transferring


The first change is that the shovel from the hardware store is showing up in the General Ledger of the co-op, not in the co-op's Accounts Payable Ledger for your purchase, and the co-op's Accounts Receivable Ledger for the hardware store's sale. After all, as far as the co-op is concerned, this is just a transfer between members. And that GL transaction is what is in the statements sent to both you and the hardware store, again not AP and AR transactions.

The second change is that this transfer is a single transaction event. A transfer is not broken into two halves like buying (payable and payment) and selling (receivable and receipt). This means that when you purchase from a fellow co-op member, your payable and payment (and the seller's receivable and receipt) happen simultaneously when entered at the credit union. They are one transaction, a single GL transfer. You don't get to make sure the shovel works before sending in a check.

That hardware store is U of M Parking, you are your department, the credit union is the Controller's Office, and the co-op is the University of Minnesota. Home Depot is still Home Depot.

Currently the central university is moving to a new financial system, and both buyers and sellers at the university are continually replacing their local systems. Yet it's important to understand that new software will not change these relationships (unless it's accompanied with a move to internal AR/AP, which essentially disbands the co-op). You are buying, we are selling. Those financial events normally have two halves (payable and payment for you, receivable and receipt for us), and normally we'd both have discretion over executing that second half. But that financial event is settled via the central university's GL. And there we are neither buying nor selling, but transferring. And transferring does not break into two halves.

And that's why you get an invoice from Home Depot, but a statement from U of M Parking.

This report (whether in display, spreadsheet, or print) is a blend of two financial documents. On the one hand it's an invoice generated out of our accounts receivable ledger and entered into your accounts payable ledger. On the other hand it's a transfer executed on the university's general ledger. Click here for a write-up on why that is.

Blending a departmental invoice and a central transfer was perhaps the trickiest piece of design work. The less you notice this blend, the more we have succeeded. But if the report is looking weird, maybe we didn't succeed too well.

Attributes in the report, especially the printout, reveal that blending.

Some central transfer (CUFS GL) attributes
1. We sort by central (i.e. CUFS) document number, not by vendor and then vendor document numbers.

2. We total at the top (as in a GL listing), and repeat those totals (document, document line, etc) after page breaks.

3. There is little vendor identity (ex: no logos, or notes of an upcoming sale).

4. Transactions look the same across vendors (ex: all are in the same font, with sequence numbers).


Some departmental invoice (your AP, our AR) attributes
1. We only accept documents that we can prefix (ex: IV PKG12345678), to allow a sort within document type by vendor.

2. We page break after change in vendor prefix, allowing headings by vendor within document type.

3. We create a table of contents by vendor, which includes contact information and vendor totals.

4. We allow select by vendor, to replicate the individual vendor invoices that staff used to receive.

5. We work with the vendor application to group items in the same entity (ex: Fleet work order, Parking budget charge card) under the same document line. This allows for the sub-totaling (ex: by work order, by parking card) that you'd expect from an invoice.


In general, we have subordinated the invoice attributes to those of the central general ledger. This seemed to be what customers wanted. However we spoke more to accountants than to managers. The former would be more concerned with reconciling to CUFS.

That subordination means that the invoice attributes suffer in at least two cases:

1. Where there are multiple CUFS seller area/orgs for a single vendor
For example, a parking budget charge from the Washington Avenue Ramp is sold out of 592-1020, while one out of the Church Street Garage sells from 592-1160. When you buy parking from us, this area/org is stamped on the CUFS document and your area/org on the CUFS document line. A CUFS document can have only one area/org. This will probably hold true for PeopleSoft too, as it does with the other financial systems we're familiar with. What that means is that your parking budget charges can spread across multiple CUFS documents, even if they're all on the same card.

A long term solution would be for our Parking department to drop to one area/org, similar to what Printing did several years ago. Whether you buy from the Chemistry Copy Center or the Coffman Copy Center, your CUFS document has a seller area/org of 591-2500. That allows them all to show up under the same CUFS document.

Reducing to one Parking area/org would provide you with this same coherence, and also drop documents at CUFS. However it would also reduce reporting abilities centrally. The central university could no longer break out ramp vs garage revenue on CUFS, but would just see both lumped together under Parking.

A short term work-around might be for you to direct this report to a spreadsheet. Highlight the budget charge card transactions (listed together on the spreadsheet, since they share common column headings). Sort and subtotal by budget charge card number. That's all the transactions bought under the card, regardless of which area/org sold them to you, and so also regardless of which CUFS document the money was transferred under.


2. Where there are multiple CUFS objects for items in a single entity
When you buy from us, your area/org is stamped on the CUFS document line. A CUFS document line (and to our knowledge, a document line in PeopleSoft or any other financial system) can only have one object. The object describes the account or category that the money is charged against (ex: office supplies or fringe benefits). We currently charge all items in a Fleet work order to CUFS object 8020-30. That allows us to aggregate the items together under the same CUFS document line, and preface them with work order header information (ex: work order number, total, date started).

Pretend however that either Fleet or the central university decided that labor and parts on work orders should be broken out on CUFS. Maybe the former stays as 8020-30, while the latter goes to 8020-40. This would split the work order items across two CUFS document lines, removing our ability to aggregate them on the statement.

As with the multiple seller area/orgs for Parking, a short term work-around would be for you to direct the output to a spreadsheet. There the work order transactions could be sorted and subtotaled by the work order number column.

But it's fair to say that both work-arounds would be a hassle for you, and not an option available on the display or print formats.