An accounting systems teacher An IT practitioner and standards wonk An accounting scholar ??

1. "Ontologically-Driven Standards Development for Business Process Systems“Bill McCarthy, Michigan State University • An accounting systems teacher • An IT practitioner and standards wonk • An accounting scholar ?? • An enterprise ontologist and computer scientist?? • An accounting practitioner ?? 1

2. Warning Label • The version of accounting you are about to hear is not the “received view” • The REA (resource-event-agent) accounting model is based on modeling of the economic primitives of a business process (exchange or conversion) • The ALOE (assets = liabilities + owners equity) accounting model is based on accounting reporting structures (double entry) 2

3. The REA ontology – Theory & Standards Use • ontology = categories of interest in a domain and the relationships among them • REA is a business enterprise (economic & accounting) ontology with: • Exchanges (in green) • Policies (in yellow) • Plans (in purple) • REA is both a positive (descriptive) and normative (prescriptive) accounting theory • For interoperability, REA is used: • in ISO Open-edi (ISO 15944-4) • UN/CEFACT – as specialization module for the UMM • For enterprise system, see Workday model • Standards use follows academic work of Geerts and McCarthy • Interoperability use needs to move up the Obrst scale, but frame-based semantics enable collaboration state machine 3

4. stockflow participation Economic Resource Economic Event Economic Agent duality M2 Level -- Elementary REA model 4

5. Cookie-Monster (the customer) and Elmo (the entrepreneur) meet in the (real or virtual) marketplace, thus setting the stage for an Economic Exchange 5

6. Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a SHIPMENT (transfer of Cookie Inventory) 6

7. Economic Resource Economic Resource Economic Agent Economic Event Economic Agent Economic Agent Economic Agent Cookies provide entrepreneur stock-flow Shipment receive customer Initiating duality Terminating receive Economic Event stock-flow provide 7 M1 Level -- Elementary REA model for exchange process

8. Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a PAYMENT (transfer of Cash) 8

9. Economic Resource Economic Resource Economic Agent Economic Event Economic Agent Economic Agent Economic Agent Cookies provide entrepreneur stock-flow Shipment receive customer Initiating duality Terminating receive entrepreneur Economic Event Payment stock-flow provide customer Cash 9 M1 Level -- Elementary REA model for exchange process

10. COOKIES COOKIES-stockflow-SHIPMENT Story of why this invoice amount to $14.75 ?? SHIPMENT-duality-PAYMENT SHIPMENT Entrepreneur# Invoice# Dollar Amount Date Customer # I-1 14.75 1JUL E-1234 C-987 I-2 20.00 2JUL E-1235 C-888 I-3 9.90 3JUL E-1236 C-999 I-4 9.20 5JUL E-1237 C-999 M0 Level – (partial) REA model for exchange process 10

11. The REA Model (ISO Open-edi accounting & economic ontology) is a pattern for a business process • Who ?  taxonomy • What ?  taxonomy • When ? 11

12. Economic Resource Type composition structure typify Goods Transport-ation Services Funds Real Estate Regulatory Service Human Services Intellectual Product (IPR) Right of Way Materials Warranty Insurance Economic Resource Services Rights Subtypes (possible) for ECONOMIC RESOURCE 12

13. Regulator Guarantor Third Party Mediator Notary Escrow Economic Agent Type Economic Agent typify Partner Buyer Seller Subtypes of Economic Agent for an Exchange 13

14. The REA Model (ISO Open-edi accounting & economic ontology) is a pattern for a business process • Who ? • What ? • When ? • Over what time period ? • Past and near present • Policy future • Scheduled future 14

15. ( the past & near present ) ( the policy future ) Rtype Etype Atype Resource Event Agent What could be or should be What actually occurred Color-coded time expansion 15

16. Policy-Level Specifications in REA Enterprise Systems Policy Level -- What Should, Could or Must be -- Knowledge-Intensive Descriptions, Validation Rules, and Target Descriptions (Standards & Budgets) Planning & Control Extended Enterprise Model T G Inference, Validation, Discrepancy Analysis Integration R E A Observation Facts Operational Level – What Actually Happens; What is -- ENTERPRISE SYSTEMS INPUT OUTPUT 16

17. type images for business process components • Typification is a conceptual abstraction of a business process component (REA) that indicates its ideal or grouped properties • the Archetypal Essence of a business object 17

18. Economic Resource Type Economic Event Type Economic Agent Type policy policy typify typify typify what archetypes provide Economic Resource EconomicEvent participation Economic Agent stock-flow M2 Level -- REA model of Exchanges & Policies 18

19. 1..1 0..* 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* ..* «EconomicResourceType» SupplyItemCategory «EconomicResource» SupplyItem «EconomicEvent» Payment «EconomicResource» Cash stockFlow 1..1 typify 1..1 - supplyItemCategoryName PK - monthlySaleAmountOfSIC - quantityOfItemOnThisTicket - remittanceAdvceNum PK - $AmountOfRemitAdvice - clientCheckNumber - cashAccountNumber PK - cashAccountBalance - supplyItemTypeNumber PK - supplyItemPrice - supplyItemQOH- receive stockflow 0..1 «EconomicAgent» BookingAgent provide - employeeNumber PK - bookingAgentCommRate 0..1 «BusinessLocation» Location «EconomicAgent» Client policy 1..1 duality - locationName PK - locationMapCoords CK - clientNumber PK - clientName site provide 1..* start finish «EconomicEvent» ExpeditionTicket 1..1 «EconomicEvent» Expedition «EventType» ExpeditionType receive distance policy-sequence - expeditionNumber PK - slotsFilledForScheduleExped - actualDuration - scheduledExpeditionDate PK • - ticketNumber PK • discountedSlotCharge • total$AmountOfSupplyItems • countOfSlotsOnThisTicket - distanceBetween - expeditionTypeName PK - expedExpectedTimeLength - standardUndiscountedSlotFee - expeditionTypeCapacity - sequenceOfLocationOnTour meronymic typify 1..1 policy participate 1..* stockflow policy-count lead participate «EconomicResourceType» AircraftType - countOfEmployeeType 1..1 participate - aircraftTypeName PK - aircraftSeatingCapacity - aircraftFuelCapacity «EconomicAgent» Pilot «EconomicAgent» Guide «EconomicAgent» ExpeditionWorker - employeeNumber PK - dateOfInitialPilotLicense - employeeNumber PK - dateQualifiedAsAGuide - employeeNumber PK «EconomicResource» Aircraft 1..* group policy- qualifies group {incomplete, disjoint} - aircraftEngineNumber PK - dateAircraftManufactured - aircraftName CK - 0..1 «EconomicAgentType» EmployeeType - hoursFlown 0..1 «EconomicAgentGroup» People «EconomicAgent» Employee - employeeType PK - startingWageForEmpType - countOfEmployeesForType - peopleName PK - approximatePopulation - employeeNumber PK - employeeName 0..1 1..1 typify 19 typify M1 Level – Typed REA model for NAAE revenue process

20. ( the past & near present ) ( the policy future ) ( the scheduled future ) Commit Event Rtype Etype Atype Rtype Etype Atype Resource Event Agent What could be or should be What is planned or scheduled What actually occurred Color-coded time expansion 20

21. reciprocal commitment commitment fulfills fulfills economic event economic event duality What is planned or scheduled M2 Level -- REA model of Scheduled Exchanges 21

22. Resource Type specifies specifies Event Type specifies Agent Type What is planned or scheduled Commitment Abstract Specification of Commitments 22

23. reciprocal Resource Type policy policy specifies specifies typifies Agent Type participate Economic Commitment specifies policy Event Type typifies fulfills typifies Economic Resource Economic Event stockflow Economic Agent provide receive duality • Green – “What has occurred” – REA, duality, stockflow {consume, produce}, participation {provide, receive} • Yellow – What could be or should be – TYPES, typify, policy • Purple – What is planned or scheduled – COMMITMENTS, specify, fulfill, reciprocal, triggers M2 Level – Extended REA model (simple & symmetric) 23

24. policyOL policyTM - laborMinutesPerUnit - minutesNeededPerUnit «EventType» Operation Type -operationTypeName PK «EconomicResourceType» «EconomicResourceType» «AgentType» Raw Material Type Tool-Machine Type -standardSequence Employee Type policyBM -rawMaterialCatalogNumber PK -toolMachineTypeDescription PK - employeeTypeName PK -quantityOwned quantityOfRawMaterialPerUnit «EconomicResourceType» -standardUnitCost - startingWage -qOH Medical Equipment Type «EconomicResource» -medicalEquipmentCatalogNumber PK Raw Material -standardUnitCost -rawMaterialTagNumber PK -standardGramWeight -dateAcquired specify specify specify1 -qOH - - - scheduledMinutes scheduledQuantity scheduledMinutes «EconomicResource» Tool-Machine -toolMachineNumber PK «EconomicCommitment» «EconomicCommitment» -dateAcquired Scheduled Manufacturing Operation Scheduled Manufacturing Run -totalMinUsedSinceAcquis - scheduledOperationNumber PK - productionOrderNumber PK - budgetedTotalLaborCost - scheduledSequence - budgetedTotalMaterialCost - budgetedTotalTool&MachineCost - projectedQuantityProduced used used - - minutesUsed quantityUsed «EconomicEvent» Manufacturing Run - manufacturingRunNumber PK «EconomicResource» - actualTotalT&MCost Medical Equipment - toDateRunLaborCost «EconomicEvent» -medicalEquipTagNumber PK - toDateRunMaterialCost Manufacturing Operation - actualQuantityProduced -actualGramWeight - initiationTimestamp PK - - actualDuration actualSequence participate participate participate - - - minutes minutes minutes «EconomicAgent» Employee «EconomicAgent» «EconomicAgent» «EconomicAgent» «EconomicAgent» «EconomicAgent» - wage Machinist Supervisor Scheduler Assembler Electrician - dateHired - - - - - - employeeNumber PK employeeNumber PK employeeNumber PK employeeNumber PK employeeNumber PK employeeNumber PK - employeeName 1..1 typify 0..* 0..* 0..* 1..* 0..* policyBM 1..* 0..* 1..1 1..1 typify 1..1 1..* 1..1 0..* typify specify 1..* 0..* 1..1 1..* 1..1 1..1 0..* 0..* 0..* specify specify 0..* 0..* 1..* 0..* reciprocal typify 1..1 typify 1..* 1..1 1..* 1..1 0..* fulfill 1..1 0..* 0..* fulfill 1..* 0..1 participate 0..1 0..* 1..* 0..1 0..* duality produce 0..1 0..* 1..1 consume 1..* M1 Level – Scheduled REA model for MME manufacturing process 0..* 0..* 0..* participate 0..* 0..* participate 0..1 1..* 0..1 1..* 0..* 24 {complete, disjoint}

25. Extended REA model for ISO 15944-4 25

26. The REA Model (ISO Open-edi accounting & economic ontology) is a pattern for a business process • Who ? • What ? • When ? • Over what time period? • Why?  (duality + sf = value chain) homo economicus 26

27. A value chain is a purposeful network of conversions and exchanges aimed at assembling the individual components of a final product (i.e., its portfolio of attributes) of value to the customer labor cash cash cookies Acquisition Process Conversion Process Revenue Process cookie ingredients A business process takes one or more kinds of input and creates an output that is of greater value to the customer . 27

28. The REA Model (ISO Open-edi accounting & economic ontology) is a pattern for a business process • Who ? • What ? • When ? • Over what time period? • Why?  (duality + sf = value chain) • How?  (through a series of small events that move business processes through to completion) 28

29. A value chain is a purposeful network of conversions and exchanges aimed at assembling the individual components of a final product (i.e., its portfolio of attributes) of value to the customer labor cash cash cookies Acquisition Process Conversion Process Revenue Process cookie ingredients • publish catalog • make sales contact • negotiate customer order • ship goods (ee) • send invoice • accept payment (ee) Workflow is a series of business events that progress a business process through its phases, leading to eventual completion (ordering is determined by state machine mechanics). A business process takes one or more kinds of input and creates an output that is of greater value to the customer . 29

30. Planning: In the Planning Phase, both the buyer and seller are engaged in activities to decide what action to take for acquiring or selling a good, service, and/or right. • Identification: The Identification Phase pertains to all those actions or events whereby data is interchanged among potential buyers and sellers in order to establish a one-to-one linkage. • Negotiation: The Negotiation Phase pertains to all those actions and events involving the exchange of information following the Identification Phase where a potential buyer and seller have (1) identified the nature of good(s) and/or service(s) to be provided; and, (2) identified each other at a level of certainty. The process of negotiation is directed at achieving an explicit, mutually understood, and agreed upon goal of a business collaboration and associated terms and conditions. This may include such things as the detailed specification of the good, service, and/or right, quantity, pricing, after sales servicing, delivery requirements, financing, use of agents and/or third parties, etc. • Actualization: The Actualization Phase pertains to all activities or events necessary for the execution of the results of the negotiation for an actual business transaction. Normally the seller produces or assembles the goods, starts providing the services, prepares and completes the delivery of good, service, and/or right, etc., to the buyer as agreed according to the terms and conditions agreed upon at the termination of the Negotiation Phase. Likewise, the buyer begins the transfer of acceptable equivalent value, usually in money, to the seller providing the good, service, and/or right. • Post-Actualization: The Post-Actualization Phase includes all of the activities or events and associated exchanges of information that occur between the buyer and the seller after the agreed upon good, service, and/or right is deemed to have been delivered. These can be activities pertaining to warranty coverage, service after sales, post-sales financing such as monthly payments or other financial arrangements, consumer complaint handling and redress or some general post-actualization relationships between buyer and seller. • SOURCE: ISO FDIS 15944-1 – Operational Aspects of Open-edi for implementation ISO Open-edi Phases of a Business Process 30

31. Extended Business Process Model (ISO 15944-1 Planning Identification Negotiation Actualization Post-Actualization Whole Business Process Model Accounting Model 31

32. UMM 32 An Example Business Process with Business Events Grouped in ISO 15944-1 Phases

33. Business Process Phases Value Chain Business Event networked Economic Resource Type Economic Agreement Business Process governs aggregate workflow establish typify specifies specifies Economic Agent Type Economic Commitment specifies reciprocal Economic Event Type typify fulfills typify Economic Resource stock-flow inside Economic Agent Economic Event outside settles duality materializes Economic Claim 33 Open-edi and UMM --> external state machine

34. UMM – the Meta Facts (Huemer & Liegl) Graphical process modeling technique for inter-organizational (B2B) business processes Concentrates on business semantics – is implementation neutral Provides a procedure similar to a software development process from requirements elicitation to process design UMM is defined as a UML profile on top of UML 2.1.1 34

35. UMM Package Structure (Huemer & Liegl) Foundation BusinessRequirementsView BusinessDomainView BusinessPartnerView BusinessEntityView BusinessChoreographyView BusinessTransactionView BusinessCollaborationView CollaborationRealizationView 35 BusinessInformationView

36. UMM Business Entity View – Business Process Activity Model (Huemer & Liegl) 36 36

37. <<BusinessEvent>> publishCatalog <<BusinessEvent>> sendAvail&PriceRequest Candidate Planned Proposed Identified Specified Actualized <<BusinessEvent>> returnAvailabilityAndPriceResult <<BusinessEvent>> sendOffer <<BusinessEvent>> acceptOffer <<BusinessEvent>> sendReceivingReport EconomicResourceType the BusinessEntityView State Machine Diagram for Economic Resource Type 37

38. <Business Event> publishCatalog <Business Event> sendCatalog <Business Event> generateResourceNeeds <Business Event> sendCatalogRequest <Business Event> receiveCatalog <SharedBusinessEntityState> :PlanningPhase [InService] <SharedBusinessEntityState> :EconomicResourceType [Candidate] <SharedBusinessEntityState> :PlanningPhase [WaitingStart] <SharedBusinessEntityState> :EconomicAgent [Candidate] <SharedBusinessEntityState> :PlanningPhase [Complete] BUYER SELLER 38 the BusinessProcessActivityModel

39. Independent view of Inter-enterprise events Enterprise #1 Enterprise #2 Business Process Business Process Business Process Business Process Business Process Business Process Business Process Business Process Business Process Enterprise #3 Trading Partner view of Inter-enterprise events (upstream vendors and downstream customers) Collaboration Perspective: Trading Partner vs. Independent Dotted arrows represent flow of goods, services, and cash between different companies; solid arrows represent flows within companies 39 Japan expert contribution to 15944-4, 22 Oct 2001, Victoria BC ,

40. Where is REA headed ?? One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw 40

41. SOURCE: Gomez-Perez & ISO 15944-4 41

42. Positioning and Formalizing the REA Enterprise Ontology-- Frederik Gailly, Wim Laurier, and Geert Poels 42

43. Modal Logic First Order Logic Logical Theory Is Disjoint Subclass of with transitivity property Description Logic DAML+OIL, OWL UML Conceptual Model Is Subclass of Semantic Interoperability RDF/S XTM Extended ER Thesaurus Has Narrower Meaning Than ER Structural Interoperability DB Schemas, XML Schema Taxonomy Is Sub-Classification of Relational Model, XML Syntactic Interoperability Ontology Spectrum: One View (Leo Obrst) strong semantics REA 43 weak semantics

44. Where is REA headed ?? • At this stage we can conclude that the REA ontology can be considered as a semantically rich business domain ontology that needs to be further formalized to make more of the inherent semantics explicit. • The bulk of REA design science research to date (see e.g. David et al. (2002)), with some exceptions mentioned in the paper, was aimed at improving REA’s content and theoretical background, but has to a considerable extent ignored representational, formalization and operationalization issues. Although we don’t question nor criticize the relevance and significance of this work, we believe that equal attention should be paid to ontology engineering aspects that aim at improving the explicitness, preciseness, completeness and formality of REA’s specification Positioning and Formalizing the REA Enterprise Ontology-- Frederik Gailly, Wim Laurier, and Geert Poels 44

45. Where is REA headed ?? • Basic ontology theory to be revised and submitted to accounting literature • Standards projects: • ISO – done for now • UN/CEFACT – a lot of work needed • Formalization initiative • Some being completed by others • Move to common logic • Workflow component must be formalized • Accounting issues on back burner: • Claims, adjustments, macro-level aggregation and duality, materialization and use of services, internal control specification, other accounting definition issues • Others ?? 45

46. “REA-Scruffie”  “REA-Neat” The world consists of: 1. Classes or objects that are • particulars--universals; • occurrents--continuants; • concrete--abstract; 2. associations between these entities/objects that are of the form • <particular , universal> e.g. is-instance-of, classification • <particular , particular> e.g. is-part-of (also u-u), aggregation • <universal , universal> e.g. isa (is-subtype-of), generalization 3. declarations, procedures, and constraints Need progress towards formal logic that enhances frame semantics with completeness, decidability, etc. 46

47. The Financial Interoperability Summit – May 12-13 2008 • Sponsored by the National Science Foundation (Frank Olken) • Looked at formal issues associated with accounting and financial interoperability at both the reporting level and the transaction level • Three main exemplars: • XBRL-FR and XBRL-GL • REA • SDMX • “REA needs to move up the semantic expressiveness scale & integrate with XBRL” • Wiki (Thanks to Brand Niemann): • http://nsfaccountingontology.wik.is/Workshop • See especially group research issues and individual positions • Summary paper coming by Debreceny and McCarthy • The big issue: Tradeoffs between semantic expressiveness, time to implement, and benefits (next slide) • “The enemy of the good is the perfect” ?? 47

48. High C Ontological Expressivity B A Low Yr 0 Time Horizon Yr 10 48 Different implementation scenarios for financial interoperability standards Benefits measured by size of circle • 1. First Dimension – Ontological Expressivity(following Leo Obrst): • -Low ontological expressivity (syntactic interoperability) with term-based thesauri and taxonomies; • - Medium ontological expressivity (structural interoperability) with semantic conceptual models (such as E-R models and UML class diagrams); and • - High ontological expressivity (semantic interoperability) with description logic based theories. • 2. Second Dimension – Time Horizon for Implementation: The implementation horizon for adoption of higher expressivity and more useful interoperability standards can range over multiple years. For the purposes of the workshop, we are limiting ourselves to an immediate – long-range spectrum of one to ten years (readily conceding that these are only present estimates). • Third Dimension – Benefits Accruing to Implementation:Implementation of ontological solutions to business problems occurs because of a suite of perceived benefits to be gained. These benefits can be estimated in a range from low to medium to high, and they may flow from some combination of improved interoperability with other standards and systems, lower transaction costs, and improved functionality for consumers of information. (SIZE of CIRCLE)

49. SMAPPIE says “Any questions??” 49