Tooling up for Internal Reporting with XBRL

Tooling up for Internal Reporting with XBRL Charles Hoffman, CPA Director of Innovative Solutions

Objectives UBmatrix shows how XBRL can be used in the process of collecting, analyzing, reusing, and otherwise managing internal operating performance data. This presentation will: • Show why an XBRL system allows a faster time to integrate with other systems • Explain why XBRL offers increased flexibility and usefulness of the reporting system • Explain why XBRL allows increased quality of reported information and reduced costs of operating the reporting system • Show a demonstration of GUI and API level functionality using XBRL

XYZ Company (actual name changed) • Problem: • 27 physical therapy clinics • Separate medical billing systems • Spread all over Washington State • Operating information needed by management daily: • Patient visits, new patients, no shows and cancellations, gross charges billed, cash received, adjustments applied • Solution?

Solution (1994) • Custom export routines from Unix and Windows based medical billing systems, CSV format, run daily • Transfer from individual systems to Windows NT system • Build a custom analysis tool using Microsoft Access 2.0. • Install Access (runtime) on 35 computers • Build custom import routine to import the CSV files. • Import data into Access • Email the Access database to 35 physical therapists and managers who received the data, daily • Repeat each day

Other such situations encountered • FR – Import GL transactions from 13 different sub systems (payroll, benefits, telephone cost allocation, etc.); Excel, fixed field text, benefits system comma delimited files, over 4500 transactions per month which were being keyed manually • FR – Sales commissions processing systems • FT – Importing data from manufacturing equipment operation logs, various text fixed field formats • WL – Custom shipping and invoicing system (DOS) into accounts receivable system (UNIX), text format • WL – Custom shipping and invoicing system from one office to another office, PC Anywhere download of database, import database, RBase • E9 – Cash register transaction dump import into custom Access database for server cash reconciliations, tax reporting and sales statistic • And on, and on, and on….

How should integration be achieved? • Custom integration is expensive to create • Custom integration is expensive to maintain • So many “small feeder systems”, either: • Manual because function MUST be performed (but likely costly and error prone) • Or, worse, important data is not analyzed • “If you can’t measure it, you can’t control it.” • Can XBRL help?

Application Data Store Application Data Store The FIRST issue Format? Pick a format, any format, or support EVERY format 1:1 programmatic validation of data transferred

Application Data Store Application Data Store The SECOND issue Say you “standardize” on ONE format, say XBRL XBRL Does not support XBRL import or export, so, have to write custom code Does not support XBRL import or export, so, have to write custom code One format, syntactic and semantic validation (business rules) to help ensure data accuracy 1:many rule engine based data validation

Application Data Store Application Data Store The future (eventually, 2005-2010???) XBRL Supports XBRL import and export Supports XBRL import and export One format, syntactic and semantic validation (business rules) to help ensure data accuracy 1:many rule engine based data validation

Steps in process with XBRL • Sending system • Create taxonomy • Map taxonomy to source of data • Build export • Validate to ensure data sent is accurate • Send data • Receiving system • Receive data • Validate to ensure data received is accurate • Read taxonomy • Map to destination of data • Build import

XBRL tools available (now, 2003) • Send/Receive one format, XBRL, rather than different formats for each internal integration built • Sending • COTS* tools for building data format specifications (XBRL taxonomies) • Some tools for mapping to data sources • Some, but not many, applications, support XBRL export • COTS software for creating instance documents • COTS software for validation of data sent • Receiving • Some software for mapping data at destination • COTS software for validation of data received • Some, but not many, applications, support XBRL import *COTS – Commercial off the shelf

XBRL tools available (2005 or 2010) • Send/Receive one format, XBRL, rather than different formats for each internal integration built • Closer to “drag and drop” application integration (clearly not in all cases) to map data source to XBRL, XBRL to data source • Many, if not most, applications support XBRL as a native import/export format • Robust domain specific semantic validation at both source of data and destination of data to ensure quality of data transferred • Web services (WSDL) used to exchange data between applications, XBRL “package” of data

Tools you need • Fully conforming XBRL processor, probably • Semantic validation, “business rules” • Create taxonomies • Create extension taxonomies in many cases • Create instance documents • Create business rules • Versioning from one version of XBRL to another, from one version of a taxonomy to another • Mapping data source/destination to XBRL

Tools available today • XBRL tools • Corel XMetaL Pro (http://www.SoftQuad.com) • DecisionSoft (http://www.decisionsoft.com) • Fujitsu (http://software.fujitsu.com/en/interstage-xwand/outline/index.html) • Semansys (http://www.semansys.com) • UBmatrix (http://www.UBmatrix.com) • Imports XBRL today (none support XBRL 2.1) • CaseWare • Creative Solutions • Navision • FRx

Demo • GUI level • API level – XBRL from Excel

Questions? Universal Business Matrix LLC 803 Kirkland Ave, Suite 200 Kirkland, WA 98033-6318 425.285.0200 www.ubmatrix.com

Universal Business Matrix LLC 803 Kirkland Ave, Suite 200 Kirkland, WA 98033-6318 425.285.0200 www.ubmatrix.com

Tooling up for Internal Reporting with XBRL