combines data from different payment systems into a common dataset;
	enhances the dataset by adding a commodity dimension and other key procurement information;
	provides insightful and powerful tools for examining and analyzing the data.

Conventional spend analysis software has drifted from this ideal. It typically consists of a collection of cleansed and mapped spend transactions, published to a data warehouse every month or quarter, with commingled services for data preparation and refresh.

So what's wrong with that?

Well, where's the "analysis?" By its very nature, spend analysis is a dynamic process, requiring changes to data structure, addition and deletion of analysis dimensions, and constant alteration of roll-up hierarchies and rules.  And, the notion of "one dataset" for spending data is highly limiting, because many different analysis views — especially commodity-specific views — are critical.

The table below itemizes some common customer requests, and how they're (not) handled by today's spend analysis systems.

Customer Request  Vendor Response  Outcome I have some {T&E data, cards data, commodity-specific data}, and I'd like to build another dataset with it.   You'll need another {server, license, implementation contract}.   We'll have to do it for you. Paralysis I need to group my {cost centers, GL codes, business units} differently for a custom analysis.   What about the other users? You can't change things out from under them.   Assuming everyone agrees, we'll do it for you next {month, quarter} at refresh time. Download raw transactions, you're on your own. I need to fix this incorrectly mapped spending, it's messing up all my results.   Assuming everyone agrees, we'll do it for you next {month, quarter} at refresh time. Paralysis I need to write a new report.   We have some canned reports. Maybe one of them will work for you.   You can't write reports. Download raw transactions, you're on your own.