OASIS LegalXML eContracts TC Requirements Process
Scenario - Enterprise Contract Management
| Name |
Enterprise Contract Management |
| Principal Stakeholders |
Legal and Contracts Professionals in Corporations and
Government |
| Scenario Owner |
[name and email] |
| Draft Number |
3 |
| Draft Date |
11 March, 2003 - Edits to take account of comments on draft 1;
re-arranged requirements into new categories; |
| 25 March, 2003 - Particulars about the information which needs
to be marked up; |
| Contributors |
- Jamie Wodetzki, jw@speedlegal.com
- Jason Harrop, jharrop@speedlegal.com
|
Introduction
This document is a scenario developed as part of the eContracts
requirements process.
The purpose of a scenario is to provide a context for a set of
requirements important to some group of end-users (in this case, Contracts
Managers). A scenario is intended to help members of the working group to
understand the drivers behind stated requirements.
To that end, this document contains a Scenario Statement, and a
set of Requirements extracted from the Scenario Statement.
As per the requirements process, contributions to this scenario are
welcome. Please send your contributions to the Scenario Owner. The
Scenario Owner will decide whether to accept your contribution or not. If
your contribution is not accepted, you may create your own Scenario. For
further details, please refer to the process document
Scenario Statement
Written contracts play an increasingly important part in the regulation
of modern business relationships and transactions. This is especially true
for corporations and governments using outsourcing and partnering to find
more efficient ways to do business. And with a growing focus on regulatory
compliance, the number and complexity of written contracts is rising
steadily.
Many large enterprises can find themselves managing hundreds,
thousands, and sometimes tens of thousands of contracts. These include
buy-side contracts with suppliers, sell-side contracts with customers, and
various other contracts with business partners, investors, employees,
etc.
Contract Management Today
Responsibility for these contracts can be shared between line managers,
contracts professionals, lawyers (internal and external) and
administrative staff. In a typical scenario, a line manager will agree the
key commercial terms of a contract; the lawyers and contracts
professionals will settle the final detailed terms and conditions (with or
without negotiation); and the line manager/s will manage the performance,
renewal and completion of the contract, often with assistance from
specialist contracts managers. The lawyers may also be called upon during
the life of a contract to assist with reviews, amendments, renewals,
disputes, etc.
In general terms, the lifecycle of a contract includes several phases:
- Contract Creation
- Contract Negotiation
- Contract Execution/Signing
- Contract Management/Performance/Amendment
- Contract Extension/Renewal
- Contract Termination/Completion/Expiry
- Contract Archiving
To date, most written contracts have been managed through these phases
manually, and with little by way of automation. A typical contract is
manually created in a word-processor; negotiated by exchanging multiple
drafts in printed or electronic form; signed as a paper document; filed
and stored somewhere (in hard and/or soft copy); and then managed (or not
managed) against key performance milestones, dates and events using some
system, which may or may not be electronic and automated.
The management of amendments in long running contracts can itself be a
major issue, as some of these amendments can themselves involve long and
complex negotiations taking months to possibly even years to negotiate.
As the volume and complexity of contracts gets greater, any problems
with this approach are becoming more acute. Many enterprises are looking
for improved ways to manage their contracts through each phase of this
lifecycle. Key business drivers for the automation of contracts management
include the need for cost savings; the need for improved compliance and
risk management; and the need for faster more flexible processes in order
to remain competitive.
Some of the problems with the current approach to contracts management
are set out below:
- Too much time is spent proofing, reviewing and signing off each
contract. When a contract is drafted using a standard word-processor,
there are no constraints on what end users can change in the document.
This means that extra care is needed to ensure document integrity - for
compliance and risk management purposes. A suitably experienced person
must manually read and check each contract to ensure that key clauses
are included, pricing is correct, correct party names are used, there
are no provisions that contravene applicable laws, regulations and
corporate policies, and so on.
- Too much time is wasted during negotiations keeping track of
multiple versions of a contract, and ensuring that changes are properly
marked up on the "right" version. With multiple copies of each draft
flying backwards and forwards between the different parties and their
advisors, it is difficult to maintain a clear audit trail showing each
consecutive draft, the changes made, who made them, when, and why they
were made.
- Time is often wasted resolving technical problems with inconsistent
document formats. Users with different WP software, or different
versions of the same software, can spend hours converting and
reformatting documents. Users can also waste valuable time cleaning up
document styles, numbering, cross-references and the like.
- Once the terms of the final contract are settled and the contract is
signed, there is no automated way of extracting key dates, milestones
and other details from the document. A "real person" has to read the
document and manually copy this data across into a contracts
management/tracking system. This increases the risk of data error, and
adds significantly to the cost of managing each contract.
- It can be difficult for finance/account managers to track the
revenue which ought to be flowing from individual contracts and the
portfolio as a whole, and reconcile actual versus expected.
- With contract data trapped inside an unstructured proprietary
document format (eg Word's .doc format), it is very difficult to prepare
useful reports across a large contract portfolio. If there's no
automated way of preparing these reports, management may not have
sufficient information to make important business decisions. For
example, if management is in negotiations involving an exclusive grant
of rights over a particular product, they need to know if any existing
contracts grant rights over the same product in a way that conflicts
with the proposed exclusivity.
- The costs of mis-managing contracts can be extremely high. Without a
system for tracking key dates, for example, it is easy to lose the
benefit of special rights and options worth thousands or millions of
dollars.
- Some contracts are required to be retained and archived for many
years, yet there is no guarantee that the proprietary document formats
in use today will be supported in years to come.
The role of XML in Contracts Management
Creating and managing contracts in a standards-based XML format will
help to solve many of these problems.
For example, with XML contracts:
- it's much easier to develop tools that ease the pain of checking and
validating document integrity.
- it's possible for different users to work on different parts of a
contract simultaneously, and for the status of different clauses to be
individually tracked over time (eg, not agreed, proposed, agreed).
- users can exchange and collaborate on contracts using a wide choice
of applications, without the document conversion pain associated with
the exchange of proprietary formats. Some users will continue to
exchange contracts in common output formats such as RTF, PDF, HTML, etc,
and it will be often be necessary for XML documents to be transformed
into these formats. However, many users will benefit from the exchange
of a native XML contract format, using a variety of XML-aware
applications.
- users can focus on getting the content right, without having to
waste time on formatting, numbering, etc. Stylesheets can be used to
ensure that consistent corporate styles and numbering are applied to the
contract in its final, executed form.
- key contract data can be intelligently marked up, so that the data
can be automatically extracted, managed, reported, and shared across a
wide variety of enterprise systems. The improvements to enterprise data
portability will greatly simplify systems integration, and will deliver
substantial cost savings.
- the document can be archived with much less risk of losing
application support over the years to come.
Examples of the types of data that enterprises need to track and manage
are set out below:
- Title of the contract. This will generally reflect the type
or subject matter of the contract, and will be useful for classification
purposes.
- Party names and details. This will make it possible to report
on contracts with particular suppliers, customers or partners.
- Dates for signature, commencement, termination, renewals,
milestones, and the exercise of special rights. For example, a company
may wish to create a report of all active contracts using these dates to
include contracts that have commenced but not expired. Or, a company may
wish to trigger a reminder of all contracts coming up for renewal 90
days before the relevant renewal date falls due.
- Value of a contract. For risk management purposes, contracts
over a particular value may need to follow a different workflow/approval
process than contracts of lesser value.
- Subject matter of the contract. In supply contracts, for
example, it will be useful to know the product or service being
supplied. Or, in licensing and technology transfer contracts, it will be
useful to know the intellectual property asset/s over which rights are
granted.
- Exclusivity, territory of rights. Contracts involving the
grant of rights may be exclusive and may be limited to certain
territories. It is important to ensure that exclusive contracts are not
granted in conflict with other contracts.
- Prices and the items they relate to. Price information often
varies across different contracts and customers and without a clear view
of the agreed price for a particular customer, there's a greater risk of
under/over charging.
- Exclusions, limitations, indemnities affecting liability
issues. For risk management purposes, companies need to understand their
overall exposure to liability across a portfolio of contracts. The
ability to identify contracts where liability is not excluded, capped or
limited allows a company to identify where its exposure is high, and
this the need to manage the risk is greater.
- Governing law of the contract. For compliance purposes, a
enterprise needs to know that contracts governed by the laws of a
particular jurisdiction have been reviewed for compliance with those
laws.
- Obligations and what has been done / not done to meet them.
- Other metadata to aid tracking and retrieval, as is relevant
given internal business processes
- Conditions precedent which trigger the operation of the
contract.
- Contract interdependencies linking head and subcontracts.
Summary of Key Benefits to Stakeholders
- Improved compliance
- Reduced costs of creating, negotiating, and managing contracts
- Better risk management
- Faster, more flexible business processes
[New] The role of eContracts XML in Contracts
Management Applications
eContracts XML can potentially be used in four parts of a contracts
management system:
- Importing an XML contract created outside the system using some
third party application
- Representing individual "instance" contracts in the system
- Representing the template contracts and/or clauses, from which
instance contracts are created
- Exporting an XML contract from the system
Discussion point: Some of the information a contract management
application may store about a contract goes beyond what it is practicable
to represent today in our XML standard. Examples may include what workflow
to initiate when a particular event occurs. This means that exporting from
one contract management application, and importing in to another using our
standard, may be lossy.
Generally speaking, information in a contract can be marked up for two
uses in a contract management application:
- Search/retrieval/filtering and reporting across a collection of
contracts
- Value added manipulation of an individual contract.
Note: Are there other uses? These two uses are referenced in the
tables below.
The information leveraged by these two uses divides in to information
common to all contracts, and information which is only found in contracts
of a certain type.
Here are some examples of types of contracts which contain additional
information beyond the core:
- Sales/Procurement contracts
- Service contracts - service widgets, managing entitlements and
coverage
- Lease contracts - eg equipment leasing
- Project contracts
- Licence of IP Rights
Note: Where a category of information identified is relevant
only to a restricted class of contracts, that limitation on its
applicability is noted below.
Requirements
Structural Requirements
Note: It is anticipated/hoped that these structural requirements
will be addressed in the TC "Structural Markup" activity.
- Ability to model the structure and content of the full range of
contracts used by corporations and government (including schedules).
- Ability to transform the contract into common output formats, with
styles, numbering and cross-references automatically applied.
- Ability to deliver a draft or the final XML eContract in its XML
format (ie as a single file which the recipient is able to work with)
"Legal Markup" Requirements
| Information item name: |
Contract Party |
| Short description: |
Details of a party to the contract - name, address, organisation
type, role, statutory id number (eg Social security number,
Australian business number) etc |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
Mandatory |
| Why capture this? |
- Search
- Management of this contract - for example, to send notices to
the party
- Contract law says a contract must have 2 or more parties
|
| Characteristics to capture |
|
Party Name
| Self-explanatory |
|
Party Address
| Self-explanatory |
|
Party Id Number
| Self-explanatory |
|
Party Role
|
- Required for search and contract management.
- Not clear yet whether choice should be from a restricted list
or not.
- More than one party can be in the same role
|
|
Solicitor/attorney
| Is this required? |
|
Party Phone/Fax/Email
| Self-explanatory |
| Notes |
Hopefully can import a pre-existing model. |
|
| Information item name: |
Effective Notice |
| Short description: |
Requirements for effective notice on a party |
| Relevant contract types: |
All contracts with a notice clause |
| Optional or Mandatory in that type? |
Optional? |
| Why capture this? |
- Search? No
- Management of this contract - send notices in the specified
manner
|
| Characteristics to capture |
|
What types of notice are valid (eg hand delivery, fax, email)
| (insert reason) |
|
When notice deemed received
| (insert reason) |
|
Party to which this information item relates
|
- Reference to a party
- One-to-one or one-to-many relationship with a party?
|
|
Person to whom notice should be sent
| (insert reason) |
|
Address to which notice should be sent
| (insert reason) |
| Notes |
(insert note) |
|
| Information item name: |
A Notice |
| Short description: |
A particular notice a party may give |
| Relevant contract types: |
All contracts ... |
| Optional or Mandatory in that type? |
Optional? |
| Why capture this? |
- Search? Yes
- Management of this contract - ..
|
| Characteristics to capture |
|
Notice title
| (insert reason) |
|
Which party may give it
| (insert reason) |
|
Recipient party
| |
| Notes |
The circumstances in which a notice may be given are defined
separately, as is the effect of giving the notice. |
|
| Information item name: |
Contract Term |
| Short description: |
Commencement, duration and expiration of the contract |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
Mandatory |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
Commencement date
| (insert reason) |
|
Conditions precedent
| Conditions which must be satisfied before the contract enters in
to force. |
|
Expiration date or duration
|
- Note that the contract could be expressed to expire on the
happening of some event - it may be sufficient to model this under
termination.
- Note that the contract could be perpetual.
|
| Notes |
Need legal expertise to refine the terminology here |
|
| Information item name: |
Contract Renewal |
| Short description: |
Procedure, time periods etc to extend the term of the
contract. |
| Relevant contract types: |
All |
| Optional or Mandatory in that type? |
Mandatory - if contract is silent or renewal is not permitted,
this should be specified. |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
Which parties may renew
| (insert reason) |
|
Notice period
| Number of days or months notice |
|
Preconditions
| eg may only renew if sales exceed $1M |
|
Procedure for renewal
| Must a party give notice etc? Or will the contract renew
automatically UNLESS .. ? Are there other procedures we need to
cover? |
| Notes |
Relationship to Notice, and Event? |
|
| Information item name: |
Termination |
| Short description: |
Contracts can often be terminated without cause (eg on notice),
or with cause (ie on certains breaches) |
| Relevant contract types: |
All, or just those with a termination and/or force majeure
clause? |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
An event which can give rise to termination
| Nature of the event, who can terminate, and what else they need
to do to make termination effective. |
| Notes |
- Should force majeure be modeled separately?
- Actions on termination are to be modeled as
obligation/permission/ prohibition aka outcome
|
|
| Information item name: |
Obligations which survive termination |
| Short description: |
Some obligations may be expressed to survive termination |
| Relevant contract types: |
(ALL or ..) |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
A flag on an obligation?
| (insert reason) |
| Notes |
This is probably just a characteristic of an obligation (however
we model those) |
|
| Information item name: |
Governing law |
| Short description: |
The law of the state/country which governs this contract. |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
Mandatory |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
Identify the jursidction
| Simple case is to specify a particular jurisdiction. But some
contracts say the governing law depends on where for example you
purchased your licence - how to model this? |
| Notes |
(insert note) |
|
| Information item name: |
Jurisdiction |
| Short description: |
The courts which have jurisdiction |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? Yes
- Management of this contract? Yes
|
| Characteristics to capture |
|
Court (one or more)
| Name of the court, and whether its jurisdiction is exclusive or
not. |
| Notes |
(insert note) |
|
| Information item name: |
Contract Event |
| Short description: |
An action-based or time-based event which may occur during the
life of the contract. |
| Relevant contract types: |
(ALL or ..) |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search?
- Management of this contract?
|
| Characteristics to capture |
|
The event
| eg notice received, goods delivered, specified date reached,
specified time period elapsed |
| Notes |
(insert note) |
|
| Information item name: |
Obligation, permission, prohibition |
| Short description: |
A Party is obliged/permitted/prohibited from doing some action
in some time frame. |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? ??
- Management of this contract? Yes
|
| Characteristics to capture |
|
Party
| Party acting |
|
Action
| The action. Types of action need to be explored more. For
example is a warranty/representation an action? |
|
Deadline or frequency
| If frequency, then we need a start and an end, which may be
absolute dates, or relative. |
|
Condition
| Any condition which must be satisfied before the
obligation/permission/prohibition is effective. |
|
Event if action occurs
| Event which happens if the action occurs |
|
Event if action does not occur
| Event which happens if the action does not occur |
| Notes |
- This item is based on On
Expressing and Monitoring Behaviour in Contracts EDOC2002 (Z.
Milosevic1, R.G. Dromey)
- Very similar to 'Outcome' item below, but more explicit about
time. Pick one!
- This information item doesn't need to say anything about
whether the action can occur after the deadline, because a second
model can be used to model that.
- Need to be clearer about the distinction (if any) between
'action' and 'event'
|
|
| Information item name: |
Outcome |
| Short description: |
An Outcome specifies what happens if a particular 'event' occurs
(and any associated conditions are satisfied. What happens may be
another event, or some workflow. |
| Relevant contract types: |
ALL |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? ??
- Management of this contract? Yes
|
| Characteristics to capture |
|
Outcome
| The result, which may be an event or workflow |
|
Event
| The action- or date-based event which leads to the outcome.
|
|
Condition
| Any condition which must be satisfied before the outcome follows
from the event. The condition might relate to timing eg frequency,
window, or deadline. |
| Notes |
- Very similar to Obligation/permission/prohibition item above.
Pick one!
- If the eContract is to be thought of as describing a finite
state machine, then it follows that the XML must describe the
valid states.
|
|
| Information item name: |
Deliverable |
| Short description: |
A good or service to be delivered under the contract. |
| Relevant contract types: |
Contracts for goods / services |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search?
- Management of this contract?
|
| Characteristics to capture |
|
Item name, Description, Code
| (insert reason) |
|
Quantity
| (insert reason) |
|
Price
| (insert reason) |
| Notes |
Placeholder - There are many other things to be considered here!
The fact that the information may be found across many clauses
suggests this should be broken down in to several different
information items, for example "Delivery", "Payment", "Transfer of
Title". |
|
| Information item name: |
Intellectual Property Rights |
| Short description: |
(description) |
| Relevant contract types: |
Licence Agreement |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search?
- Management of this contract?
|
| Characteristics to capture |
|
Subject matter
| (insert reason) |
|
Rights granted
| (insert reason) |
|
Sole or exclusive?
| (insert reason) |
|
Royalties or licence fee?
| (insert reason) |
| Notes |
(insert note) |
|
| Information item name: |
Clause Details |
| Short description: |
Is this a standard clause, or one drafted specifically for this
agreement? |
| Relevant contract types: |
(ALL or ..) |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search? Useful for identifying non-standard contracts.
- Management of this contract?
|
| Characteristics to capture |
|
Standard or non-standard
| (insert reason) |
| Notes |
(insert note) |
|
| Information item name: |
Confidentiality |
| Short description: |
The scope of any confidentiality provision. |
| Relevant contract types: |
Contracts with a confidentiality clauses. |
| Optional or Mandatory in that type? |
(choose) |
| Why capture this? |
- Search?
- Management of this contract?
|
| Characteristics to capture |
|
Who owes the obligation
| (insert reason) |
|
To whom is the obligation owed
| (insert reason) |
|
Nature of obligation
| (insert reason) |
| Notes |
Is confidentiality important enough to model separately from
other obligations? |
|
Flexibility to allow specific organisations to mark-up additional data
relevant to its internal operations.
MetaInformation Requirements
- Ability to break the document into clauses, sections, articles and
other "modules" so that the status of specific clauses, etc, can be
tracked
- Ability to identify the changes between different versions of a
clause
- Ability to identify the changes between different versions of a
contract
- Ability to capture the reasons for a change, when made, and by whom
(for audit trail purposes).
Other Requirements
- Ability to break the document into clauses, sections, articles and
other "modules" so that different authors can work on different modules
- Ability to check the actions of the parties to determine whether
there is (or is likely to be) a contract breach
- Ability to analyse history; risk assessment; performance measurement
of trading partners
Notes
[Any additional notes]. |