The document discusses best practices for data governance. It recommends establishing a data governance framework that defines common terminology, hierarchies, and change management processes. It also emphasizes integrating applications like ERP, EPM, BI, and data warehouses by mapping data relationships and dimensions in a centralized data governance solution. This enables a single version of truth and reduces data reconciliation work across various systems.

1. The best of data governance

2. Contents
3 Executive summary
5 Data governance framework
7 Evolution of data relationship management
8 What makes good data governance?
Common terminology
Integrated applications
Mapping
Hierarchies
Change management and workflow
13 Data governance in action
Chart of accounts
Acquisition onboarding and scalability
Sales and organization hierarchies
16 Conclusion

3. Executive summary
The best of data governance
A good place to start is with your structured financial chart
of accounts data. Managing internal financial structures and
extending to other operational areas — product definition,
customer grouping, HR employee roll-ups and sales organization
definition — enables you to achieve value-driven predictive
and prescriptive analytical functions. The key to mastering data
is not necessarily in the data itself, but how you relate it to the
proper business context of what the data represents. Without the
structures and hierarchies that are used for categorization and
reporting, a piece of transactional data has no connection to the
meaning of how your company uses the data. For example, an
employee’s name can be used for HR purposes, while the same
employee’s name can be used as part of a sales team that covers
branch locations or pursues new customers.
Proper governance will enable change in the organization and
alignment of processes to support business analytics. However,
too much discipline can be restrictive and can sacrifice the agility
and ability to support varying requirements across the enterprise.
There is a point of optimal data governance that you should aim
for (see Figure 1).
Obtaining value from business analytics and cloud services requires perspective and
discipline. Grant Thornton LLP believes that data governance drives effective analytics and
you can’t be effective in one area without the other. Mastering internally owned content is
an important step to providing the ability to evaluate external sources of content as part of
the big data evolution.
Figure 1: Business impact of data governance
Minimum
data governance
Amount of
data governance
Negative
business
impact
Business
impact
Point of optimal
data governance
0
Diminishing return
Source: Oracle Big Data Handbook, Oracle Press, 2014.

4. 4 The best of data governance
Data goverance should be applied to both financial and
nonfinancial areas and be part of the roadmap for getting value
from big data (see Figure 2). Managing business hierarchies and
data relationships with effective controls is the first step to good
business analytics. The structured data sets, which cross financial
and operational functions, will bring the proper context when
merged with external customer data and related unstructured
sources of information.
This white paper highlights data governance practices that were
applied to leading companies and varying business functions to
provide for structured data to be related to unstructured data.
We’ve applied these practices and related solutions for over a
dozen years, and evolved with enhancements in technology,
corporate governance processes and government regulations.
The best of data governance is intended to leverage existing
investments in infrastructure platforms, business intelligence (BI)
and data warehousing to provide the right level of governance to
expand into big data.
Figure 2: The road to big data
• Information discovery
Structured data
Unstructured data
Big data
• Prebuilt analytics
• Foundation analytics
Governance and integration
• Financial consolidation
• Budgeting and forecasting
• Profitability and
cost management

5. Data governance framework
Leading companies take the time to put a data governance
framework in place. A framework should be relevant to both their
business strategy and application footprint, and enable process
improvement. To use analytics for competitive advantage, you
must balance procedures that enable higher-quality data controls
with maintaining agility for varying business stakeholders. A
company’s framework should allow for data to be optimized for
both corporate standards and local/divisional use.
Grant Thornton’s position on data governance enables
interdependent solution components to provide for disparate
operational processes and performance management applications
to work together as one unified solution. As such, a company
with various business-specific applications can utilize data
governance principles to bring the pieces together into one single
solution, while providing for a distributed change management
solution across a diverse set of business stakeholders.
Terminology and hierarchy
of data, change control and
multiple versions of data
Processes for the
workflow, maintenance,
protection (security),
support of organizational
information
Tools/technologies related
to software applications,
data synchronization
and integrated data
architecture
Competencies and
organizational structure to
support information delivery
Strategy
Measures
Structure
(Terminology
and hierarchy)
Process
(Workflow,
controls and
maintenance)
Architecture
(Technology
and protocols)
People
(Competencies
and execution)
Figure 3: Data governance framework

6. 6 The best of data governance
Furthermore, a data governance framework establishes
strategies, objectives and policies for effectively managing an
organization’s data. It consists of the people, processes, structure
and architecture required to manage the availability, usability,
integrity, consistency and auditability of secure data. A well-
implemented data governance framework will transform data
to information and ultimately knowledge, which will enable
repeatable fact-based decision-making.
A data governance framework has the following characteristics
around the data:
• Includes definitions of term, metrics, items, customers and
related elements (Structure)
• Distinguishes dimension values from the analytics of
hierarchy definition (Structure)
• Makes/collects/aligns rules (Process)
• Assigns accountabilities to resolve issues (Process)
• Organizes data stewards and governance bodies (People)
• Monitors/enforces compliance while providing ongoing
support to and change management for broad stakeholders
(Architecture)
The need for data governance
We have worked with companies that struggle with operational
issues related to growing the business, compliance and regulatory
pressures, and restructuring the organization. Implementing data
governance can help these companies deal with the issues by
helping them manage change more effectively.
We recommend the move to formal data governance when one of
these five major changes occur:
1. Traditional management cannot address cross-functional
activities as the organization has grown.
2. An organization’s data systems get so complicated by
numerous functional activities that multiple definitions of
common business entities begin to permeate the data systems.
3. Regulation, compliance or contractual requirements call for
formal controls to ensure data integrity and avoid risk.
4. An organization’s data architects, service-oriented architecture
teams, or other horizontally focused groups need the support
of a cross-functional program that takes an enterprise (rather
than siloed) view of data concerns and choices.
5. Organizations wish to empower decentralized management
of the business under a parameter-based overall
governance framework.
Consideration of the company’s overall objectives is essential to
effective data governance. Understand what your business needs
from its data, then use that knowledge to create a data governance
framework that directly ties into those needs. Governing data
requires a rethink of your operating model, with new roles,
responsibilities and processes emerging.

7. Evolution of data
relationship management
Oracle Data Relationship Management (DRM), a leading
data governance solution, has been around for more than 15
years and had its beginnings in the pioneer days of master data
management. DRM was originally developed to allow very
acquisitive companies to deal with the high rate of change that
goes along with constant reorganization. While these companies
initially used spreadsheets to do the premerger planning and
postmerger mapping, they quickly realized that without a
repeatable, business-user driven process, the success of the
acquisition was at risk. The initial release of DRM provided this
acquisition framework, but its configurable, multidomain model
allowed it to also be used for ongoing master data and hierarchy
maintenance as well. By its second release, it was a full-blown
governance application that was being used to manage all master
data domains and hierarchies at the enterprise level.
Today, the average DRM customer manages 9+ data domains
within DRM, including the chart of accounts, products,
employees and customers. A few years ago, DRM was expanded
to include a formal data governance module that fully supports
the RACI matrix for data governance standards, and allows
requestors, stewards and approvers to participate in workflows
around master data and hierarchy change management.1
Grant Thornton’s Business Analytics team has been using
dimensional modeling concepts and functions that are now part
of Oracle’s DRM for over a dozen years, since deploying a global
solution at one of the world’s largest alumina manufacturers. We
implemented a data governance solution to manage financial,
customer, and vendor change control procedures, while reducing
audit costs and providing controls to reduce risk. The client
benefited from the solution with (a) the ability to close the books
in three business days and be the first to report earnings on Wall
Street; and (b) a two-day reduction in days sales outstanding and
over $1 million in annuity savings, among other results. Since this
initial project, the Grant Thornton team has implemented more
than 100 Oracle DRM solutions. We draw from that experience
to describe the common functions that have been used in leading
data governance solutions.
1
See section “Change management and workflow” for more information on RACI.

8. 8 The best of data governance
Common terminology
Without a common language, data cannot communicate
successfully across systems and people can’t be optimized to
improve organizational processes. When dealing with multiple,
disparate applications — regardless of the number of software
vendors or products involved — terminology matters. It’s
meant to link processes and applications, but that linkage is
not always easy to accomplish. Business terms referring to
accounts, products, customers, employees, geography and other
domains may vary across the transactional or BI applications.
Additionally, some systems may have a finer level of granularity,
adding more complexity to building clean analytics.
What makes good data governance?
Organization
and process
People
Product
SuppliersCustomers
Financials
People
ProductFinancials
Figure 4: Terminology across functions
Companies need a common language for systems to adopt
in order to relate. As information is shared across enterprise
performance management (EPM) and transactional ERP systems,
this common language — defined by agreed-upon hierarchies and
attributes — creates business context for how a company performs
analytics. It is acceptable to have different terminology for
various applications, but the differences must be linked through
hierarchies or mappings to provide effective business analytics.
Integrated applications
ERP, EPM, BI applications and a customer-specific data
warehouse all serve different business functions. But as part of the
integrated technology platform, you need to establish governance
and define the hierarchies that will be used across different
applications in order for them to work together. For example,
total revenue by month for external reporting should relate
balance to total revenue by location and product for that same
month. Furthermore, alternate hierarchies for data should be
shared with the appropriate applications that require the analysis.
Oracle functions
In the Oracle ecosystem, Oracle DRM can serve as the host and
origination of the chart of accounts for ERP systems. However,
this is not an absolute mandate; the transactional system can be
the originator. It does not always matter which system hosts the
chart, employee or sales structure, as long as there is a means
to manage alternate hierarchies of the business for analytics,
and that the appropriate system attributes are captured for each
application and process to effectively communicate. Additionally,
there should be a single point of entry, with controls over the
entry process, and automation between transactional systems and
the data governance solution.

9. The use of master hierarchies in a data governance solution can
reduce maintenance and improve analytics for disparate EPM
and BI applications. Specifically for Oracle Hyperion-based
applications that predominately report financial trial balance
information, a data governance solution can be used as the
shared library to store all business dimensions for the vendor,
customer, product and chart of accounts. The Hyperion-specific
dimension repository manager provides the application-specific
libraries, using the same hierarchies for summary trial balance and
journal detail across multiple EPM and BI applications, or other
databases can be deployed.
An important concept to note: For prebuilt BI applications
where the data warehouse is provided out of the box, there are
account groupings created for balance sheet and income statement
reporting. Grant Thornton uses an accelerator with DRM to
reuse financial account groupings so that hierarchies are managed
once in DRM for use across multiple EPM and BI applications.
This enables varying applications to have the same structures
of data even if they go to a finer level of detail. This approach
provides for increased transparency, reduced data reconciliation
effort and a high level of auditable data.
Explore your options
Consider your business structure and complexity, the systems
and processes already in place, and your reporting needs. One
approach might be to source all hierarchies and dimensions
from a data governance solution that pushes to transactions, BI,
EPM, etc. Another option is to have ERP host new accounts or
products, then determine and load net changes into DRM. DRM
augments the hierarchies, adds hierarchies, provides attributes,
and then shares information with downstream applications (data
warehouse, EPM, BI).
Most companies desire a single version of truth and try to achieve
that objective through deploying function-specific applications
that provide a certain level of content that expires with the
passing of time. Other companies have built data magnets or data
warehouses to store large volumes of detail and summary data.
Grant Thornton recommends a paradigm shift to consider the use
of data governance processes and technologies as the mechanism
to obtain a single version of truth for multiple stakeholders.
While you can buy the latest and greatest software, without a
data governance solution or a light version of governance, the
applications won’t connect to each other. After a labor-intensive,
manual process to synchronize the data — a short-term solution
— you can have the truth for only a point in time. You need
the right integrated applications, methodology and governance
process to control the data and reduce risk.
Govern
Rationalize
ShareControls Hierarchy
structure
EPM
• Planning
• Consolidation
• Profitability
EDW
• Subject area marts
• Source marts
ERP
• PeopleSoft
• eBusiness
• JD Edwards
BI
• OBI financials
analytics
Figure 5: Data governance integrates applications

10. 10 The best of data governance
Business unit
Department
Account
Affiliate
Operating unit
Operating
unit affiliate
Project ID
Product
Subproduct
McKesson, EBS,
Macola, Meditech
Mapping
Mapping relates to differences in names (cost center, department,
accounts, product, etc.) between applications, which occurs for a
number of reasons:
• Converting or upgrading from one ERP to another
• Redefining a new corporate chart of accounts
• Acquiring a new company
• A subsidiary entity is not part of the standard ERP
• Applications are developed for business unit
driver specifications
In many cases, the mapping or scrubbing of names is bundled
under a transformation process called extract, transform and load
(ETL) procedures, which is owned by IT. However, the names
and organization of the new members are known best by finance,
sales management, product management or other functional
areas of the business. Organizations have a real opportunity to
enable the business to define the terminology and structure that
supports business analytics, which can then be shared with IT
systems. This opportunity is particularly important for audit and
government regulations in providing controls on changing certain
types of data.
• Represents highest-level organization of recorded business information
• Creates and provides multidimensional reporting
Corporate code
Department/
cost center
Account
• Smallest budgetary unit
• Described by function
• Defines transactional classification
• Natural account (monetary and/or statistical)
• Ties to business unit
• Balances intercompany transactions automatically
• Regional designation
• Matches operational flow of the organization
• Ties operating unit
• Balances intercompany transactions automatically
• Captures cost collection activities with a beginning and end date
• Additional project chart fields are available to track project attributes/tasks
• Defined by standard DRG codes
• Used to classify patients based on service and procedure
• Tracks ICD-9 code and rolls up to DRG code
PeopleSoft
FSCM
DRM
Figure 6: Example of mapping

11. Oracle functions
Oracle provides a data load and data transformation mechanism
that is typically used by finance administrators called Oracle
Financial Data Quality Management (FDQM). This application
typically manages the data load and, if necessary, the data
mapping of multiple general ledger accounts and related systems.
The benefit of the FDQM application is that finance departments
have a flexible means to load and map data for external financial
reporting purposes. However, this mapping is purpose-specific
and would need to be recreated for other uses. Other business
applications would need to set up processes to remap the data.
Oracle provides a robust ETL tool called Oracle Data Integrator
for financial and nonfinancial mapping and transformation of
data across the enterprise. In this case, the IT professional has to
perform the definition and code updates for the remapping.
Regardless of the technology used, the data relationship and
mapping of business dimensions can and should be defined by
functional business teams, with controls in place for executive
approval, while providing the logic to IT to automate. To avoid
the remapping process, Grant Thornton recommends using DRM
to define the business logic and provide the mapping definition
and controls, which are then automated for use by FDQM,
Oracle Data Integrator, or any transformation technology.
Hierarchies
Data governance should distinguish between and provide
specific processes for both (a) dimension or chart of accounts
values, and (b) hierarchies. The values have specific characters
that are required for use within a customer relationship or ERP
transactional system, where hierarchies provide the information
for reporting. Hierarchies give you the context to understand
data — big or small. Businesses have many applications that serve
different purposes: planning and budgeting, workforce planning,
capital asset planning, sales force analytics, HR retention
analytics, general ledger, accounts payable analytics and inventory
reporting. These applications may have different hierarchies and
levels of detail for good business reasons and application-specific
best practices.
Below is an example of a product hierarchy where the corporate
application shows the level for analysis and Lidoderm, and the
transactional system shows the stock keeping units and detailed
values that map to the parent product.
Figure 8: Product hierarchy — Transactional system
Figure 7: Product hierarchy — Corporate application
Pain_Brands
Lidoderm
Pain Brands
Lidoderm
01000LID10687
63481-687-01
63481-687-02
63481-687-06
Pain Brands
Lidoderm
01000LID10687 Lidoderm 5%
63481-687-01 Lidoderm Envelope
63481-687-02 Lidoderm (Lidocaine Patch 5%) x 2
63481-687-06 Lidoderm (Lidocaine Patch 5%) x 30
LidodermLidoderm
63481-687-0163481-687-01
63481-687-0263481-687-02
63481-687-0663481-687-06

12. 12 The best of data governance
Change management and workflow
The core of data governance is change management through
human workflow. The workflow aspect of governance allows
requestors to participate directly with the change management
process. Without automated workflow, end users typically
communicate to data stewards via email or phone calls or Excel
templates. Automated workflow as part of governance formalizes
the change request process, allowing the rules and flows to be
codified and reused.
However, governance is not just workflow; it also includes
the concept of the RACI model to help identify roles and
responsibilities during a change process.
RACI is an abbreviation for:
R = Responsible: the person or group that owns the data
A = Accountable: the person or group that must approve the
requested change
C = Consulted: the person or group that has information that is
necessary to complete the data
I = Informed: the person or group that should be informed
about the data change
Figure 9 illustrates the workflow stages that Oracle supports in
the RACI model (the “I” in RACI is supported via notifications
at each stage).
Oracle DRM provides a module to configure business-driven
workflow so that the right business audience has the information
at the right time to approve, while providing the required IT
controls to pass strict audit and regulatory requirements.
Figure 9: Workflow stages
Request Approve Enrich Commit

13. Chart of accounts
As technology evolves, we recommend having the latest ERP
functions and support. The chart of accounts can be tested for
adoption prior to making a full system refresh. Additionally, the
chart of accounts can be migrated with an audit trail to both old
and new chart field values. Figure 10 shows an example where
multiple charts of accounts coexisted.
A leading health care company used this approach with its new
chart. After using the same chart of accounts for over a decade,
the company was looking to make a change to their financial
reporting and controls process. The CFO wanted to implement
a management reporting solution with a new chart of accounts
prior to implementing it in the ERP and desired a test drive of
the new chart, along with the old chart. This would allow the
company to see how the new chart would work for the business
as part of the process and prior to upgrading the ERP platform.
The implementation of a data governance platform enabled
multiple charts of accounts to coexist and provided for the
company to ultimately implement improvements in the ERP.
We designed a new chart for this company and implemented
Oracle DRM with Oracle BI Foundation Suite and Hyperion.
The results: executive and end-user reporting to over 2,000 users,
and a new chart of accounts with access to general ledger journal
detail, vendor detail and additional accounts payable transactions.
Reporting access at the detailed level provided both the old
and the new chart values and descriptions to assist with change
management and end-user adoption.
Most companies wouldn’t proceed this way. They would follow
a textbook method of updating the ERP, implementing the new
chart, building Hyperion planning and building out reporting
capabilities. However, that approach is capital intensive. In this
case, we inverted the solution for our client — and it worked. We
ultimately updated their ERP because the management reporting
of the chart was such a success.
Upgrade
PeopleSoft
Redo
COA design
Functional
upgrade
Management
reporting
ERP ERP ERP BI
Upgrade
PeopleSoft
Data
governance
Functional
upgrade
COA
Redesign
Management
reporting
ERP BI ERP
Typical linear approach
Enhanced approach
Integrated ERP
and EPM
Provided management
reporting in a new chart
of accounts without changing
the underlying ERP
Figure 10: Approaches to new chart of accounts
Data governance in action

14. 14 The best of data governance
1.
Request COA
hierarchy
export
from DRM
15.
Review
mappings
and conduct
data validation
2.
Generate COA
hierarchyexport
for subsidiary
10.
Add new sub
GL structure
12.
Integrate new
DRM mappings
to FDM
5.
Create
hierachies
in DRM
11.
Validate
EPMA
structure
changes
ODI admin
16.
Configure ODI
14.
Conduct FDM
actual load
testing
19.
Promote
subsidiary
onboarding
development
work
3.
Initiate
subsidiary-
specific
application
objects
17.
Set up source
access
security
4.
Populate
template
with ERP
values
13.
Send FDM
files to DRM
6.
Map subsidiary
COA to
corporate COA
8.
Update
mapping
15.
Review
mappings
and conduct
data validation
7.
Conduct
mapping
workshop
18.
Sign off on
structures,
mapping,
security and
data
9.
Validate
mapping files
Acquisition onboarding and scalability
Growing and dynamic organizations that are looking at strategic
acquisitions should be particularly aware of the capabilities of
their data governance solution, which should incorporate MA
functions. To support your growth strategy, you’ll need to enable
the organization to take on additional financial systems. The
solution should include corporate consolidation and planning
applications that reconcile seamlessly to underlying journal
and function-specific details. With a data governance solution,
mapping and business hierarchy information should be able
to relate from the newly acquired company for corporate use.
Ideally, using the data governance processes and mechanism
deployed, the newly acquired entity should be integrated
smoothly into the standard ERP platform.
In our experience, we’ve been able to provide a repeatable process
to onboard new companies. For one client, a leading life science
organization, we helped create a data process to seamlessly
integrate new acquisitions — not just for basic financial statement
reporting, which is at the external financial statement level, but
also for trial balance level, general ledger journal detail, and
vendor and spend data. We helped this company implement an
integrated solution with Oracle DRM to be able to link different
applications together. We also created an acquisition integration
playbook (see Figure 11) that defined steps and processes to
onboard a new company. By following this playbook, the client
was able to provide financial statement level information within
seven days of acquisition and full trial balance information within
30 days of acquisition.
Finance
DRMadminITSubsidiaryGovernance
Figure 11: Acquisition playbook example

15. Sales and organization hierarchies
Data relationship management can be applied and used for sales
territory and organization definition. For our financial services
client, different trading, financial and customer applications are
used. Oftentimes hierarchies are shared across these applications,
such as team structure, which starts with HR and the definition
of employee. However, for revenue-generating and sales
management purposes, the employee becomes part of a team that
is part of a branch or location. We’ve created multiple hierarchies
for this same individual in order to support analytics and
decision-making across varying business applications.
Instead of sharing the data relationship between applications,
companies often copy and set up redundant information for
application-specific uses. Best practices would be to classify how
that employee relates to a branch, division, geographic entity
and business unit. Then data relationship management should
provide sales and organization hierarchies with all the relevant
alternate hierarchies that are used to support the analytical needs
of other applications.
For example, HR applications use hierarchies that include
employee and position structures. Employees may also have a
hierarchy for payroll and performance management, which can be
different for the employee structure for a sales or product delivery
team. Having all of the relevant data elements for an employee is
part of data management. Hierarchies for the specific application
use should be governed since the relationship of transaction data
to your reporting hierarchies will drive your analytics. A data
relationship management tool will manage alternate hierarchies
used for different applications, and assign attributes and
application-specific DNA (codes and symbols for applications).
Data relationship governance is the foundation for managing
your enterprise-level hierarchies and attributes.

16. 16 The best of data governance
A data governance solution provides for effective change
management within departments and across the organization.
Organizations can be agile when dealing with growth strategies,
including product acquisition and business unit reorganizations.
Alignment of people, process and technology can be achieved
effectively and in a timely basis with proper data governance
protocols in place.
The journey to big data begins with mastering your internal
content so that your organization has the context to discover
trends when external variables are added to the competitive
equation. Using information as an asset requires a strong
foundation. Without the right data governance, success with
analytics may be both expensive and ineffective. The effective
implementation of data governance techniques and tools (such
as Oracle Data Relationship Management) can provide that
necessary control and governance for master data management,
while supporting the need for flexibility. With data relationship
management, you can achieve both agility and financial reliability
through alignment.
Opportunities and benefits can extend beyond the finance
function as business measures and hierarchies exist everywhere.
Then once governance is established with fundamental structured
data, you are on your way to reaping the benefits of advanced
analytics — competitive advantage, performance improvement
and growth.
The best of data governance, and its principles, will provide the
direction to establish the procedures to reduce risk while enabling
analytics to drive organizational outcomes.
Conclusion

17. Joseph Coniker
Principal, Technology Solutions
Grant Thornton LLP
T +1 412 901 5216
E joseph.coniker@us.gt.com
Contact
Doug Cosby
Vice President, Software Development
Oracle
T +1 512 336 1778
E doug.cosby@oracle.com
References
Peel, Robin; Dwight, Christopher; and Kamath, Rahul.
Achieving Agility through Alignment: The Case for Data
Relationship Management (DRM), December 2008.
About the Authors
Joseph Coniker is a principal with Grant Thornton and
national practice leader for business analytics. Coniker
has over 20 years of experience, including 15 years in
Oracle solution delivery. His projects have resulted in
over $1 billion in working capital improvements, including
account receivable collection, vendor payment, inventory
optimization and cost allocation reduction — all of which
served as components to delivering increased product and
customer profitability, using information as an asset. Coniker
is a graduate from New York University Stern School of
Business and Harvard Business School.
Doug Cosby, in his role as vice president of software
development at Oracle, manages the team that designs and
develops the Oracle Data Relationship Management product.
He was the founder of Razza Solutions, the company that
originally created the DRM product, and has been working in
the master data management space for 20 years.

18. About Grant Thornton LLP
The people in the independent firms of Grant Thornton International Ltd provide personalized attention
and the highest-quality service to public and private clients in more than 100 countries. Grant Thornton LLP
is the U.S. member firm of Grant Thornton International Ltd, one of the world’s leading organizations of
independent audit, tax and advisory firms. Grant Thornton International Ltd and its member firms are not a
worldwide partnership, as each member firm is a separate and distinct legal entity.
In the United States, visit grantthornton.com for details.
Content in this publication is not intended to answer specific questions or suggest suitability of action in a particular case. For additional information about the issues
discussed, consult a Grant Thornton LLP client service partner or another qualified professional.
“Grant Thornton” refers to Grant Thornton LLP, the U.S. member firm of Grant Thornton International Ltd (GTIL). GTIL and its member firms are not a
worldwide partnership. All member firms are individual legal entities separate from GTIL. Services are delivered by the member firms. GTIL does not
provide services to clients. GTIL and its member firms are not agents of, and do not obligate, one another and are not liable for one another’s acts or
omissions. Please visit grantthornton.com for details.
© 2014 Grant Thornton LLP | All rights reserved | U.S. member firm of Grant Thornton International Ltd
Connect with us
grantthornton.com
@grantthorntonus
linkd.in/grantthorntonus