in fig1 , a purchase card maximization system 10 (“ cardmax system ”) is to provide an easy to use , standardized method to measure and report the performance of a purchasing card (“ pcard ”) operation within in enterprise network 12 . through the use of common web - based technologies , it measures the purchases of an organization to determine the percentages of applicable purchases made on the pcard versus those made through other means . by doing this , the cardmax system 10 is able to show not only the purchases that were made on the pcard , but also , the missed opportunity of purchases that could have been made on the pcard , by parts of an organization , types of purchases , and specific vendor candidates . there are three primary sources of data for the cardmax system 10 . pcard purchasing data (“ pcard transaction data ”) 14 that provides a list of purchases made during a specific period . generally the pcard transaction data 14 includes the date of purchase , the vendor , the amount and the identifying codes ( e . g . cost center ) used by the organization . the second source of data is general ledger ( gl ) accounting data , or “ non - pcard transaction data ” 16 , that provides a list of expenses logged during a specific period that includes the date of expense , the vendor , the amount and identifying information about the expense . the third source of data is control / selection data 18 that provides a list of codes that should be accepted as valid categories of expenses and lists of cost centers and cardholders by which to group transactions . the gl accounting data 16 may include many types of expenses that may not be applicable to pcard purchases , which may be filtered by the control / selection data 18 so that only applicable expenses are included and analyzed . the enterprise network 12 is illustrative of an organization having a segregated procurement and accounting system 20 that includes a firewall - protected portion 22 . the non - pcard transaction data 16 resides in the firewall - protected portion 22 upon a purchasing application 24 used for procurement actions . the control / selection data 18 resides within an accounting application 26 that is also within the firewall protected portion 22 . the purchase card maximizer 10 also resides within the firewall - protected portion 22 . each of the applications 10 , 20 , 26 interface to a database ( db ) server 28 and hence to a db storage medium 30 , both of latter also residing in the firewall protected portion 22 . the illustrative depiction of fig1 depicts a decentralized architecture wherein the procurement and accounting system 20 is interfaced to an external web server 32 , which includes a cardmax user interface ( if ) 34 . a customer interfaces to the cardmax user interface 34 via a service terminal 36 in order to perform function such as uploading the purchase card transaction data 14 from a purchase account facilitator 38 ( e . g ., a financial institution ). the purchase account facilitator 38 mediates and tracks purchases made by a plurality of account holders (“ client ”) 40 - 44 with a number of vendors 46 that provide goods and services . each account holder 40 - 44 has a respective purchase account (“ pcard ”) 48 - 52 . within the organization , the account holders 40 - 44 may be advantageously grouped into cost centers 54 , 56 , enabling analysis of management and efficiency of various subgroups . the interactions between account holders 40 - 44 , vendors 46 , the customer service terminal 36 , and the web server 32 are depicted as passing through a communication network 58 , which may include or comprise in its entirety one or more of a digital network ( e . g ., internet ), telephone network , wireless network , local area network , wide area network , and other means apparent to those skilled in the art having benefit of the present disclosure . the customer ( e . g ., cardmax administrator ) is able to configure the purchase card maximizer 10 through the service terminal 36 , such as selecting data formats , excluding certain vendors from analysis , creation of certain data extracts . the cardmax administrator is also able to generate performance reports for a given time frame , showing by demographic group the amount and number of purchases made through the purchasing card and those made through other means . they will make it easy to highlight areas of the organization that are effectively using the purchasing card and those that have opportunity for improvement . the cardmax administrator is also able to generate improvement reports for an area of the organization , specifying actions that can be made in the future to improve pcard performance . it will also be appreciated that comparisons may be made between different organizations for benchmarking purposes . this capability enables comparisons by demographics , such as type of industry or length of time the pcard program has been implemented . in fig2 , an exemplary “. net ” implementation is depicted for the purchase card maximizer 10 , including pages and modules 60 that interface to the web server 32 components 62 coupled to the pages and modules 60 , and applications 64 coupled to the components 62 and to the db server 28 . the pages and modules 60 and 61 include hypertext pages implemented in asp + ( also called asp . net ), which is the next generation of microsoft &# 39 ; s active server page ( asp ), a feature of their internet information server ( iis ). both asp and asp + allow a web site builder to dynamically build web pages on the fly by inserting queries to a relational database in the web page . asp + is different than its predecessor in two major ways : it supports code written in compiled languages such as visual basic , c ++, c #, and perl , and it features server controls that can separate the code from the content , allowing wysiwyg editing of pages . although asp + is not backward compatible with asp , it is able to run side by side with asp applications . asp + files can be recognized by their . aspx extension . the pages and modules 60 include a web . config asp . net configuration file that contains configuration data on each unique url resource used in the project . a default . aspx page is a welcome page with the short description of the tools and methodology to analyze the performance of the purchase card program . interface controls are accessed from the default . aspx page , specifically scripts . vb , a simple data class that contains support functionality for the user interface , and a styles . css styles class that contains information used for support the style of the user interface . a footer . ascx user control is used to display copyright line at the bottom of all web pages . a header . ascx user control is used to display header information at the top of all web pages . this control is also responsible for creating submenu information corresponding to each web page . a menucolumn . ascx user control is used to display menu information . the scripts . vb data class in turn accesses a number of sub - pages : a logon . aspx page class is used to authenticate a customer &# 39 ; s supplied user name / password credentials against a database . a pcmcalccycle . aspx page class is used to calculate purchase card performance for the chosen cycle . a pcmcctreeadd . aspx page class is used to add a new cost center to the cost center hierarchy . a pcmcctreebld . aspx page class is used to set a cost center hierarchical display . a pcmcctreeexcl . aspx page class is used to exclude cost centers that are not participating in the purchase card program for the cycle . a pcmcctreerpt . aspx page class is used to display cost center performance by analyzing applicable purchases through a cost center hierarchy . a pcmcctreerpt2 . aspx page class is used to display and compare cost center performance for the two different cycles . a pcmchart . aspx page class is used to display purchase card performance charts for the chosen cost center from a cost center hierarchy . a pcmconfig . aspx page class is used to give user ability display and change configuration parameters , add new cycle and update existing cycle . pcmcostcenter . aspx page class is used to display filtered cost center list in order to update it . a pcmdataload . aspx page class is used to perform initial data load , load list of valid gl codes , load gl data for cycle , load purchase card transactions data for cycle . a pcmnews . aspx page class is used to provide current news of interest to cardmax administrators . a pcmpref . aspx page class provides controls for modifying the use interface . a pcmreport . aspx page class is used to display newly created purchase card reports or load existing reports . a pcmvendor . aspx page class is used to display filtered vendor list in order to exclude / include vendors from / into purchase card program . an errorpage . aspx page class is used to return to the user information that invalid event has occurred . a pcmauditlog . aspx page class is used to display filtered cardholder list in order to analyze cardholder &# 39 ; s activity within predetermined cycle period . a pcmchtreedisp . aspx page class is used to display cardholder &# 39 ; s activity through a cost center hierarchy within predetermined cycle period . a pcmreceiptlog . aspx page class is used to display filtered cardholder list in order to obtain logged / non - logged receipts information . a pcmchmgmt . aspx page class is used to manage and assign cardholder information . a pcmcalccomply . aspx page class is used to calculate compliance measurements for a cycle . the components 62 are implemented in visual basic ( vb ), which is a programming environment from microsoft in which a programmer uses a graphical user interface to choose and modify preselected sections of code written in the basic programming language . a configdb . vb business / data logic class encapsulates all data logic necessary to update / query config table within the purchase card maximizer ( pcm ) database in db storage 30 . a costcenterdb . vb business / data logic class encapsulates all data logic necessary to add / update / query cost center management tables within the pcm database . a cycledb . vb - business / data logic class encapsulates all data logic necessary to add / query cycle management tables within the pcm database to generate cycle results . a datamgmtdb . vb business / data logic class encapsulates all data logic necessary to add / update / query data management tables within the pcm database . a lookupdb . vb business / data logic class encapsulates all data logic necessary to add / update / query lookup tables within the pcm database . a reportdb . vb report logic class encapsulates all data logic necessary to add / update / query report tables within the pcm database . a treeroutinesdb . vb business / data logic class encapsulates all data logic necessary to create cost center hierarchical display . a userdb . vb simple data class encapsulates details about a particular pcm user . a vendordb . vb business / data logic class encapsulates all data logic necessary to update / query vendor tables within the pcm database . a waitforreport . vb class module checks report status in order to display the report in needed format . an audit . vb business / data logic class encapsulates all data logic necessary to perform analysis of the activity of groups of cardholders within predetermined cycle period . a cardholderdb . vb business / data logic class encapsulates all data logic necessary to analyze the information about cardholder &# 39 ; s activity . a masterdb . vb business / data logic class encapsulates all data logic necessary to navigate a user to their specific instance of the cardmax database . the applications 64 include programs that effect the preparation of the analyses . a glcodes . exe application loads a list of valid gl codes into the pcm database . a chdetail . exe application loads cardholder data into the pcm database . a chemail . exe application loads cardholder email addresses into the pcm database . a gldetail . exe application loads gl data for the cycle into the pcm database . a pcdetail . exe application loads purchase card transaction data for the cycle into the pcm database . a processpcm . exe application detects and executes any request from the user to load data into the pcm database , to create reports , or to create charts . a chartpcm1 . exe application creates purchase card performance charts and stores them in the pcm database in jpg format . a rptspcm1 . exe application creates purchase card performance reports and store them in the pcm database in pdf format . fig3 - 7 depict relationships between tables and fields used respectively to upload purchase account transactions , prepare account holder reports , create a report , to support company specific interfaces and preferences , and data processing and report preparation . in fig4 , a data download capability 66 includes a users table 68 ( having fields usersid , emailaddress , firstname , lastname , password , company , addr1 , addr2 , city , state , zipcode , and phone ) that is linked via key field userid to datauploads table 70 ( having fields datauploadid , fileformatid , userid , cycleid , dateuploaded , dateprocessed , processstatusid , errmessage , and upddatafile ). the users table 68 is linked via key field userid and datauploads table 70 is linked via key field cycleid to a cycle table 72 ( having fields cycleid , c - description , locked , cycledate , and userid ). the datauploads table 70 is linked via key field fileformatid to a fileformats table 74 ( having fields filetypeid , fileformatid , fileformat , fileformatdesc , and processobject ). the datauploads table 70 is linked via key field userid to a userfileformats table 76 ( having fields userid and fileformatid ). the datauploads table 70 is linked via key field cycleid to a processstatus table 78 ( having fields processstatusid and status ). the fileformats table 74 is linked via key field filetypeid to a filetypes table 80 ( having fields filetypeid and filetype ). in fig4 , an account holder report capability 82 includes a cardholderresults table 84 ( having fields cycleid , accountno , cardholderid , pcamount , and pctrancount ) is linked via key field cycleid to a cycle table 86 ( having fields cycleid , c - description , locked , cycledate , and userid ). the cycle table 84 is linked via key field userid to the users table 68 , to a pcdetail table 88 ( having fields userid , pcdetaillid , costcenter , glacct , pcdate , pctype , vendorid , pcdesc , pccardholder , pcaccountno , pcamount , pctranamt , pcacctinfo , and cycleid ), and to a cardholders table 90 ( having fields userid , accountno , costcenterid , costcenter , chname , chname2 , chaddress , chcity , chstate , chzipcode , chemail , chphone , status , createdate , initialcycle , and lastauditcycle ). in fig5 , a report creation capability 92 is achieved by linking the users table 68 via key field userid to a reportinstance table 94 ( having fields reportinstanceid , userid , rptid , rptdesc , createdate , completedate , dit , saverpt , rptdata , rpterror ). the reportinstance table 94 is linked via keyfield reportinstanceid to a reportcriteria table 96 ( having fields criteriaid , reportinstanceid , critname , and critvalue ). the reportinstance table 94 is also linked via a keyfield rptid to both a reports table 98 ( having fields rptid , rptname , rpttitle , rptprocess , and outputtype ) and to a reporttable table 100 ( having fields reportid , costcenterid , glcounter , gltotalamt , pccounter , pctotalamt , cycleid , and excludefrommetrics ). in fig6 , a support table capability 102 includes a mailqueue table 104 ( having fields mailqueueid , messageto , messagefrom , messagesubject , messagetext , attachmentfilename , datesent and userid ) for managing automail distribution of reports . a config table 106 ( having fields configid , userid , cnfparameter , cntvalue and cnftype ) stores individual configurations for each cardmax administrator . a company table 108 ( having fields companyid and companyname ) allows an installation of cardmax system 10 to service multiple organizations . in fig7 , a data processing and report preparation capability 110 is depicted . the users table 68 is linked via key field userid to the cycle table 86 , which in turn is linked to a cycleresults table 112 ( having fields costcenterid , cycleid , glamount . gltrancount , pcamount , pctrancount , and excludefrommetrics ). the users table 68 is also linked to a costcenters table 114 ( having fields costcenterid , costcenter , cckey , ccname , cccontact , ccemail , autoemail , excludefrommetrics , userid , and newcckey ), to a glcodes table 116 ( having fields userid , glacct , and glacctdesc ), to a vendors table 118 ( having fields vendorid , userid , vendorname , excludefrommetrics , and inuse ), to the pcdetail table 88 , and to a gldetail table 120 ( having fields gldetailid , userid , costcenter , glacct , gldate , gltype , vendorid , gldesc , glamount , glacctinfo , cycleid , pcardtrans , and pcardaccount ). the vendors table 118 , the gldetail table 120 , and the pcdetail table 88 are also linked to one another by key field vendorid . in fig8 , a sequence of operations , or procedure 122 , is depicted for purchase account use optimization , an illustrative use of the pcard maximizer 10 of fig1 - 2 to analyze the use of purchase accounts . in block 124 , the purchase card customer is initialized in the system , which advantageously includes establishing a customer user id and password , defining a data file formats that is to be used in merging transaction data , identifying valid general ledger codes for the types of transactions to be analyzed , initializing storage locations for transaction data to be received ( e . g ., non - purchase account transactions , purchase account transactions ), setting configuration parameters for the user interface , and establishing the analysis cycles . additionally , in some situations , a pcard maximizer 10 might be configured to gather data related to audits of purchase card transactions , and the software used in the step of initializing a purchase card customer into the system 124 might be implemented in such a way as to facilitate the gathering of audit data . for example , in some situations a user might be presented with an interface which allows the user to define a plurality of rules which could be used in audits of purchase card transactions . such rule definition might take place in a variety of manners . fig1 a and 14 b show an example of an interface which might be presented to a user to allow rules to be defined by modifying parameters in a library of pre - existing rules . in fig1 a - 14 b , a plurality of rules ( shown as rules a 1 - a 14 in fig1 a ) are displayed for the user to potentially modify and / or use . to modify a rule the user would click on the expansion control [ 1401 ] for the rule and be presented with a list of parameters [ 1402 ][ 1403 ] which control that rule &# 39 ; s operation . in fig1 b , the parameters [ 1402 ][ 1403 ] are shown as having default values [ 1404 ][ 1405 ] which can be modified as appropriate by the user . once the parameters [ 1404 ][ 1405 ] had been edited appropriately , or if the user wishes to activate the rule without changing the parameters , an activation control [ 1406 ] for the rule could be selected , thereby indicating that the rule should be used in future audits with the given parameters . of course , it should be understood that the interface as shown in fig1 a and 14 b is intended to be illustrative only of one potential interface which could be presented , and therefore should not be treated as limiting on claims included in this application , or in other applications claiming the benefit of this application . as a potential extension on the interface depicted in fig1 a - 14 b , consider a situation in which rules are segmented according to category . as an example of such segmentation , consider that the rules shown in fig1 a - 14 b are identified as having the type of “ account management ,” which should be understood as meaning rules which are used to audit the organization sponsoring the purchase card program . other categories which might be used to segment rules include “ transactional ,” which should be understood as meaning rules which are used to audit particular transactions in the purchase card program and “ cardholder ,” which should be understood as meaning rules which are used to audit individual cardholders participating the purchase card program . such a categorization could then be presented to a user , who could choose which type of rule he or she wishes to define , thereby facilitating finding the correct rule in a library of predefined rules . of course , it should be understood that the description of the use of rule categories is not intended to be limiting on the scope of techniques which can be used to facilitate the definition of rules , and that other techniques and tools could be implemented by those of ordinary skill in the art without undue experimentation in light of this disclosure . as an example of another tool which could potentially be used to facilitate the process of rule definition , consider the interface shown in fig1 a - 15 b and 16 . fig1 a and 15 b depict an interface which can be used to model the effects of a rule without putting the rule into place . using the interface of fig1 a - 15 b , a user can define a range through which to test various values for the parameter of a rule , and at what granularity and in what time period the user wishes to perform the tests . specifically , fig1 b depicts a minimum value [ 1501 ] which is the smallest value in the range which the user wishes to test the parameter . fig1 b also depicts a maximum value [ 1502 ] and a step value [ 1503 ] which are , respectively , the values for the largest value in the range which the user wishes to test the parameter , and the granularity with which the user wishes to test the parameter . fig1 a also depicts a time frame [ 1504 ] to use as a data set for testing the parameter . thus , the values of the interface shown in fig1 a - 15 b could be used to indicate that the user wishes to see what would happen if the rule t 17 had been in effect during the selected time period , having parameter values between 5 and 25 , increased in increments of 5 . then , a second interface [ 1601 ], such as shown in fig1 , could be presented to the user to indicate the results of the test . using that information , the user can determine the appropriate value for the parameter , resulting in a rule which is able to catch suspect transactions , but which is not so easily triggered as to generate excessive false positive results . of course , it should be understood that the interfaces of fig1 a - b and 16 are depicted for the purpose of illustration only , and that alternate interfaces ( e . g ., an interface which combines the information presented on fig1 a - b and 16 ) could be implemented without undue experimentation by one of ordinary skill in the art in light of this disclosure . in block 126 , cost centers are managed , which includes setting a hierarchical representation or display ( e . g ., relationships between cost centers ), and modifying individual costs centers ( e . g ., adding , editing , or deleting ). it will be appreciated that purchase account holders are assigned to cost centers as part of initializing or editing their information . it should also be appreciated that organizing the hierarchical representation in terms of cost centers is simply an exemplary form of organization , and that other hierarchies could also be defined . for example , in instances in which a pcard maximizer is implemented to facilitate auditing , the hierarchy could be defined in terms of the audit or organization , rather than in terms of cost centers . as such , there could be a hierarchy in which the positions in the hierarchy are determined by the organization chart of the sponsor of the purchase card program ( e . g ., department heads could be placed above managers , who could in turn be placed above employees ). as another alternative , there could be a hierarchy in which positions on a hierarchy are assigned according to audit responsibilities ( e . g ., final reviewers might be placed above intermediate reviewers , who might be placed above auditors , who might be placed above the specific purchase cardholders they are responsible for ). further , in implementations where a pcard maximizer is used to facilitate audits , the hierarchy could be used to define the scope of rules . for instance , a rule applied to a node in the hierarchy might automatically be applied to that node and all descendants of that node . of course , other variations , such as node by node rule definition and assignment could also be used . thus , the description of a hierarchy determined by cost centers , and the description of the use of that hierarchy , should be understood as being illustrative only of possible applications for the techniques disclosed herein , and not limiting on the scope of claims included in this application , or in other applications claiming the benefit of this application . in block 128 , transaction data for the cycle to be processed and analyzed are uploaded into a pcm database . this uploading includes loading a list of valid general ledger ( gl ) codes from the control / selection data table 18 . it also includes loading gl data ( i . e ., non - purchase account transactions ) from the general ledger expenses database 16 . it also includes loading purchase account transactions data for this cycle from the purchase account transactions database 14 , which typically has been retrieved from a third party . in block 130 , exclusions for the cycle are set , wherein cost centers or vendors that are not participating in participating in the purchase account operation are excluded in order to focus on transactions that are appropriate for analysis . in block 132 , purchase card performance of the organization for the cycle is calculated . the vendors that have been excluded are not included in the results . the cost centers that have been excluded are calculated , but are not included at reporting or charting time . with the amounts calculated , then in block 134 , the purchase card program performance is analyzed . advantageously , analyses may include measuring and displaying cost center performance for the cycle by analyzing applicable purchases through a cost center hierarchy , comparing performance across two different cycles , and highlighting areas of the organization in need of improvement . in block 136 , the cardholders &# 39 ; activity is analyzed , which advantageously may include displaying cardholders for the cycle by auditing current cardholders activity through a cost center hierarchy , and displaying filtered cardholder list in order to obtain logged / non - logged receipts information . of course , it should be understood that utilizing a pcard maximizer for auditing logged / non - logged receipts for cardholders organized into a hierarchy of cost centers is intended to be an illustration only of a potential application of the techniques described herein , and that other applications could be implemented by those of ordinary skill in the art without undue experimentation . for example , in some circumstances , a transaction audit rule might be defined which limits the types of vendors where a purchase card could be utilized ( e . g ., no purchases at adult entertainment facilities ). in such a case , the vendors for each purchase card transaction could be categorized , with forbidden expenditures being flagged as audit violations . similarly , it is possible that , instead of ( or in addition to ) auditing purchase card transactions , rules might be used to audit the structure of the organization sponsoring the purchase card program . for example , there might be an account management rule which states that no one cost center will have more than ten purchase card holders associated with it . as yet a further variation which might be made to facilitate auditing using a pcard maximizer , consider the interfaces of fig1 a - 17 b and 18 a - 18 b . those interfaces show how lists of questions [ 1701 ] and actions [ 1801 ] which can be used to facilitate the audit process can be defined . in fig1 a - 17 b , an interface is shown in which a plurality of predefined questions ( e . g ., q 1 , q 2 , q 3 ) are shown , along with associated check boxes [ 1702 ] which can be used to select those questions . the selected questions could then be used to obtain information explaining any violation of transaction rules during an audit of purchase card transactions . similarly , in fig1 a - 18 b , an interface is shown in which potential responses to audit violations can be selected , for example , by using check boxes [ 1802 ]. the use of selected questions and action can facilitate auditing in a variety of manners . for example , in a circumstance in which audit responsibilities are organized into a hierarchy with two levels of review above auditors who actually examine transactions , lists of questions and actions such as could be defined using the interfaces of fig1 a - 17 b and 18 a - 18 b might be used to standardize information communicated throughout the hierarchy , and / or to define appropriate responses to audit violations . in practice , this might work as follows . first , if one of the transaction rules indicates that a problem exists , an auditor might review the flagged transaction and determine the cause of the violation , and to reach an appropriate proposed reaction . the cause of the violation , along with the proposed response could then be communicated to the intermediate reviewer , who could sign off on the response and explanation , or might forward the information regarding particular transactions to the final reviewer ( e . g ., in instances where exceptional sanctions , such as cardholder termination , are indicated ). as another alternative , the reviewer could request further information about particular transactions , or might request that the auditor implement an alternate response to particular violations . of course , other alternatives are also possible , and could be implemented without undue experimentation in light of this disclosure . as yet a further variation which might be made to facilitate auditing using a pcard maximizer as described above , in some circumstances , a pcard maximizer might be implemented in a manner which is adapted to comprehensiveness of audits . for example , by applying predefined sets of audit rules to transaction data collected by the system , it is possible to perform a 100 % automated audit on all transactions made through a purchase card program . however , in some cases , it might be desirable to avoid having a 100 % automated audit . for example , there might be an internal policy which requires that a sponsor of a purchase card program manually review at least some minimum amount ( e . g ., 10 %) of transactions during any audit . in such a case , the pcard maximizer might be configured with a rule which states the percentage ( or absolute number ) of records to be manually reviewed in a given period , and the system might then randomly select records for manual review until the sponsor organization &# 39 ; s requirements had been met . as another example , in a case where a sponsor organization has a policy which includes review of certain transactions ( e . g ., intermediate reviewer sign off on responses to violations ), the pcard maximizer might track whether the necessary review had taken place , and might issue reminders , either to the tardy reviewer , or to that individual &# 39 ; s supervisor , when the review had not taken place within a given time period ( e . g ., two weeks after being reported ). further similar modifications and extensions could also be made . thus , the discussion of auditing set forth herein should be understood as being illustrative only , and should not be treated as limiting on claims included in this application or in other applications claiming the benefit of this application . fig9 depicts an illustrative graphical user interface ( gui ) screen 138 for manually inserting such selections and information , although it will be appreciated that repetitive or default settings may be loaded for one or more new customers . the configuration management mode link 140 is selected on a mode task bar 142 , which also includes a data processing , end - of - cycle processing , and reporting and analysis links 144 - 150 . the sub - page selections on the mode task bar 142 are changed to reflect the mode selected . for configuration management mode , the sub - page selections are a home key 152 , a logoff key 154 , a configuration key 156 , a cycle maintenance key 158 , a cost center management key 160 , and a cardholder management key 162 . in the sub - page frame 164 , an example of a graphical hierarchical representation is depicted of cost centers of an organization and an approach to cost center management ( e . g ., relating cost centers to one another ). the sub - page selections on the mode task bar 142 are changed to reflect the mode selected . for configuration management mode , the sub - page selections are a home key 152 , a logoff key 154 , a configuration key 156 , a cycle maintenance key 158 , a cost center management key 160 , and a cardholder management key 162 . in a sub - page frame 164 , an example of a graphical cost center hierarchical representation 166 , which is presented in response to selecting cost center management mode key 160 , depicts cost centers of an organization and an approach to cost center management ( e . g ., relating cost centers to one another ). although not depicted , another interface is presented for each sub - page selection link . for instance , selection of the configuration link 156 would also entry or modification of parameters for use in the pcard maximizer : audit percent per cycle , audit score count , audit score labels , cardholder audit tree level , legend descriptions , mandatory audit cycle , maximum cycles without audit , metric dollar limit , metric low limit , and metric warning limit . fig1 depicts the gui screen 138 wherein the data processing mode link 144 has been selected , which in turn displays a list of available sub - page selections on the task bar 142 : the home link 152 , the logoff link 154 , an upload data link 168 , a process data link 170 , an exclude data link 172 and a calculate cycle performance link 174 . the upload data link 168 has been selected , displaying a “ load pcard usage data ” form 176 on the sub - page frame 164 . fig1 depicts the gui screen 138 wherein the recurring tasks mode link 146 has been selected , which in turn displays a list of available sub - page selections on the task bar 142 : the home link 152 , the logoff link 154 , an apply rules link 178 , a cost center view link 180 , a reports and charts link 182 , and a review compliance link 184 . the selected reports and charts link 182 has in turn displayed a performance rating report 186 in the sub - page frame 164 . thereby , the cost centers are listed with the totaled amounts of all purchases (“ ap amt ”), amounts of all purchase card transactions (“ pc amt ”), the number of line items of ap transactions , the number of line items of pc transactions , and a percentage calculation of the pcard transactions as compared to total ap transactions that were not excluded for purchase card use . fig1 depicts the gui screen 138 with the recurring tasks mode key 146 and reports and charts link 182 selected as in fig1 , but further with a top potential vendors report 188 depicted in the sub - page frame 164 . in particular , the total dollar amount of transactions and number of transactions are depicted of applicable procurement actions that could have been performed with a purchase account , with the corresponding missed savings tabulated . fig1 depicts the gui screen 138 with the end - of - cycle processing mode key 148 selected , which in turn displays sub - page selections of the home link 152 , logoff link 154 , a cost center view link 198 , a log receipts link 200 , an audit results link 202 , an audit results link 204 , a calculate cycle compliance link 206 , a reports and charts link 206 , and a review compliance link 208 . selecting the audit results link 202 results in an “ enter audit results ” table 210 on the sub - page frame 164 . this table 210 allows selecting a portion of the cardholders for auditing . in response to selecting a subgroup ( e . g ., last name beginning with “ a ”) and a cycle ( e . g ., january 2002 ), a listing of cardholder names , the dollar amount of their procurements , number of transactions , and count of total possible points achievable for these transactions ( e . g ., 2 per transaction ). the customer reviews the file , inserting the number of receipts received and the number of transactions for which the tax was entered correctly . if correct in both instances for each transaction , then the total amount of points is achieved , with the percentage thereof calculated . the customer also marks that the audit was performed for tracking audit compliance . fig1 depicts the gui screen 138 with the metric calculator mode key 150 selected , which in turn displays sub - page selections of the home link 152 , the logoff link 154 , a rules link 212 , a create metric link 214 , a load metric link 216 , a delete metric link 218 , and a reports link 218 . selection of the latter link results in a “ pcard metric calculator report ” 220 being displayed on the sub - page frame 164 . this report tabulates the time and expense and responsible party entailed in performing each step of the transaction in either the normal procurement process of the purchase account process . in the illustrative depiction , the categories and specific steps are as follows : exclude cost centers that are not participating in the purchase card program for this cycle vendors that have been excluded are not included in the results cost centers that have been excluded area calculated , but will not be included at reporting or charting time measure and display cost center performance for the cycle by analyzing applicable purchases through a cost center hierarchy display cardholders for the cycle by auditing current cardholders activity through a cost center hierarchy display filtered cardholder list in order to obtain logged / non - logged receipts information . in use , non - purchase card transaction data 16 and purchase card transaction data 14 are analyzed by a purchase card maximizer 10 for an organization , which includes excluding vendors and / or cost centers that are not applicable for purchase account use ( e . g ., referencing control / selection data 18 ). opportunities are identified by cost center for cost savings that could be realized through increased use of a purchase account . by virtue of the foregoing , the interests of the organization are furthered by hierarchically analyzing purchase account usage for the organization . while the present invention has been illustrated by description of several embodiments and while the illustrative embodiments have been described in considerable detail , it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail . additional advantages and modifications may readily appear to those skilled in the art .