1. © 2002 Six Sigma Academy and Helix Systems1 Interface Overview Version 1.0

2. © 2002 Six Sigma Academy and Helix Systems2 Interface File: Orientation Nightly Incremental Data Feeds from Source A/R Systems. Changed/modified data only is extracted, transaction parenting occurs, Residual or Partial payment methodology treatment applied, and cash movement activity. Data validation and integrity checked against trailer file(s). Business Unit X Business Unit X Business Unit Y Business Unit Z METREQMETREQ SourceA/RSystemsSourceA/RSystems OracleSAPJDEOther…

3. © 2002 Six Sigma Academy and Helix Systems3 Interface File: Process Overview Identify Source Accounting System and scope of coverage Evaluate Source A/R System Operating Environment, Business Rules and Data, Size infrastructure Requirements Business develops Source System extract file and applies appropriate extract processing logic and data modification requirements Identify and allocate appropriate resources Validate data and tied-out to source A/R Control totals and data integrity checks performed Data Integrity? no yes Validated ? no yes Determine the Root Causes of Errors Elevate to Production End Start Correct Programming Errors Send extract to Metreq

4. © 2002 Six Sigma Academy and Helix Systems4 Interface File(s) Data Contents The METREQ data feeds are transactional based – meaning that only the activity to Customer and/or Transaction records is sent to METREQ in the interface data feed. Further, METREQ DOES NOT send data ‘upstream’ to the source A/R system (System of Record). The interface files are produced and sent to METREQ on a schedule determined by the organization – typically each evening. Because METREQ is transactional based, the system maintains Source System Double-Entry accounting. All debits and credits are monitored, tracked, and applied appropriately. METREQ maintains all open AND closed transaction items – to include all transaction data (all Debit and Credit activity), line item details, and comment activity. Items reflect the true and accurate status within the Source A/R system – For Example: an item will remain open in METREQ until closed in the source A/R system… the ‘closing’ activity is subsequently captured, send to METREQ, and the item is closed within METREQ. Further, because METREQ maintains all closed items, it is able to re-open a transaction should it become re-opened within the source A/R system – e.g. a credit is applied. The retaining of closed items also enables trending and long term process capability analysis and performance measurements, cash forecasting, and goal deployment activities.

5. © 2002 Six Sigma Academy and Helix Systems5 Interface Files METREQ incorporates the use of multiple data files to extract, process, format, and deliver the receivables data from the Source A/R system.  Customer Master  Transaction Master  Transaction Line Item  Bill-To Master  Ship-To Master  Synchronization These files are used in both pre-production initialization as well as steady-state. During initialization of the system these files will deliver current-state account and transaction detail to METREQ. Post-Initialization, a.k.a. “Steady-State”, the data contained in the interface files will be incremental in nature – or Activity Based, covering a time range specified by the organization. In addition, in conjunction with system initialization, METREQ may receive a Historic Data Load from the source A/R system. The historic load contains the following files and accompanying data  Customer Comments  Customer Contacts  Invoice Comments  Dispute Detail

6. © 2002 Six Sigma Academy and Helix Systems6 Organization and Data Relationships Business Organization Relationships Customer Organization Relationships Transaction Organization Relationships METREQ utilizes and relies on relationships in three key areas for functionality of the application: These relationships determine the treatment and workflow processes applied to the receivables.

7. © 2002 Six Sigma Academy and Helix Systems7 Business Organization Relationships Defines the organizations reporting, strategic, and operational relationships as related to business organization and accountability 100% Definable and Configurable by the business Example: Strategic Business Unit (SBU) “A” Strategic Business Entity (SBE) A1 Line of Business A1A Profit Center A1A1 Profit Center A1A2 Profit Center A1A3 Line of Business A1B Strategic Business Entity (SBE) A2 Strategic Business Entity (SBE) A3 METREQ refers to these Business Organization Relationships as the “Organizational Hierarchy” METREQ refers to these Business Organization Relationships as the “Organizational Hierarchy”

8. © 2002 Six Sigma Academy and Helix Systems8 Customer Organization Relationships Defines your customers organization structure Allows a Single-Voice treatment to the customer across multiple lines of business Different relationship definitions may exist between collection activities and reporting/risk management activities Facilitates and enables consolidated customer risk management and reporting activities 100% Definable and Configurable by the business – ability to segment, or “break” relationships for alternate treatment at any level – Across A/R platforms Example: METREQ Strategic Customer ACME 1 METREQ Strategic Customer ACME 1C METREQ provides the flexibility to define and treat the customer as the situation requires. METREQ refers to these Customer Organization Relationships as “Parenting”, or “Strategic Customers” METREQ refers to these Customer Organization Relationships as “Parenting”, or “Strategic Customers”

9. © 2002 Six Sigma Academy and Helix Systems9 Transaction Organization Relationships Double-Entry accounting activity is maintained and captured Item activity must carry and identify the original (or Parent) invoice number/identifier Item activity, e.g. offsets, are identified to the original item by carrying the Parent Identifier Associated Item activities are managed and grouped with the original item/transaction – full history is maintained for all items. METREQ refers to these Transaction Organization Relationships as “Transaction Parenting” METREQ refers to these Transaction Organization Relationships as “Transaction Parenting”

10. © 2002 Six Sigma Academy and Helix Systems10 Transaction Organization Relationships Transaction Parenting Example: The Original Item Number MUST BE carried in the Parent Invoice Field Important: Item Number must be carried in the Parent Invoice Field for the Original Transaction

11. © 2002 Six Sigma Academy and Helix Systems11 Transaction Organization Relationships There are two Cash Application Methodologies:  Residual Payment Methodology: –A new and unique Debit Item is created for each credit item that doesn’t fully offset the debit (e.g. Short-Payment) –A new and unique Credit Item is created for Over-Payments against an item  Partial Payment Methodology –The original invoice remains open until fully offset by either Debits or Credits Requirements for/in METREQ  If a Short-Payment is encountered, only the payment information is sent to METREQ –Remember: Must include the Parent Invoice Number in the Parent Invoice Field !!!  Residual Items should NOT be sent to METREQ  If offsetting transactions aren’t created in the Source A/R system they MUST be created as part of/in the Interface Program The Cash Application Methodology and Configuration in the Source A/R Systems MUST be reviewed and addressed…

12. © 2002 Six Sigma Academy and Helix Systems12 Transaction Organization Relationships Transaction Parenting and Cash Application Illustration #1 Typical “Straight Forward” Scenario… This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are four activities sent to Metreq This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are four activities sent to Metreq

13. © 2002 Six Sigma Academy and Helix Systems13 Transaction Organization Relationships Transaction Parenting and Cash Application Illustration #2 Typical “Straight Forward Multiple Payment” Scenario… This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are seven activities sent to Metreq This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are seven activities sent to Metreq

14. © 2002 Six Sigma Academy and Helix Systems14 Transaction Organization Relationships Transaction Parenting and Cash Application Illustration #3 Typical “Multiple Invoice, Single Payment” Scenario… This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are seven activities sent to Metreq This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are seven activities sent to Metreq

15. © 2002 Six Sigma Academy and Helix Systems15 Transaction Organization Relationships Transaction Parenting and Cash Application Illustration #4 Typical “Straight Forward Multiple Payment” Scenario… This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are four activities sent to Metreq and that the Original Invoice item remains open This example represents Source A/R System activity. If off-setting transactions are not captured in/by the Source A/R system, the interface process/program must generate them and send them to Metreq. -Note that in the above example, there are four activities sent to Metreq and that the Original Invoice item remains open

16. © 2002 Six Sigma Academy and Helix Systems16 Interface Considerations System Configuration  Business Organizational Relationships, or “Organizational Parenting”, configuration  Which transactions to/are associated with the various business levels  Identify and define Resolvers by business level/entity – who owns the responsibility for the various transaction/dispute types within each business level  Escalation paths –Across business levels –Across A/R systems Source System Cash Application Treatment  Residual Payment Methodology  Partial Payment Methodology  Automatic Write-off configurations –Write-off activity must be captured and fed to Metreq  The treatment of cash movement between customer accounts

17. © 2002 Six Sigma Academy and Helix Systems17 Interface File Development Data Mapping Functional Design Design Review  Review source system configuration and data treatment  Validate approach and logic Development Reviews  Demonstrate ability to provide Transactional Organizational Relationship, “Transaction Parenting”, under all scenarios  Review Code and Logic  Review Data Validation –Trailer Records –Synchronization Files –User “Eyeball” validation  Elevate to Production

18. © 2002 Six Sigma Academy and Helix Systems18 Production Elevation Criteria Interface file development is complete when:  Source A/R System Ties out and balances with Metreq at the following levels… –System –Customer –Business –Transaction  There are no rejected records

19. © 2002 Six Sigma Academy and Helix Systems19 Interface Development Process Flow

20. © 2002 Six Sigma Academy and Helix Systems20 Interface Development Process Flow

21. © 2002 Six Sigma Academy and Helix Systems21 Interface Development Process Flow