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 |
Jason Harrop, jharrop@speedlegal.com |
Draft Number |
4 |
Draft Date |
7 Feb, 2003 - Initial Draft
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;
27 March, 2003 - Feedback from 26 March teleconference; suggestions in Jim Keane post to mailing list
|
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 Performance, Amendment, Claims and Disputes
- Contract Extension/Renewal
- Contract Termination/Completion/Expiration
- 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
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. |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
This Agreement is made between Walpiri Media Association Inc (here after called WMA) of Yuendumu via Alice Springs, NT.
and LP P/L of 1 Collins Street, Melbourne (hereinunder called the Company)
| this first example... |
The Federal Ministry of Education and Research
of the Federal Republic of Germany
and
the Department of Energy
of the United States of America recognizing...
| ... |
This Agreement is an agreement between you and XYZ Inc and applies to your use of the services provided.
This Agreement affects your rights and you should read it carefully. In this Agreement, "you" or "your" means any person
or entity using the Service ("Users"). Unless otherwise stated, "XYZ Inc" "we" or "our" or "us" or "site" will refer collectively
to XYZ Inc and its affiliates, directors, officers, employees, agents.
| In this example, one of the parties is not specifically identified. |
|
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) |
See Also | A Notice
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
NOTICES: Notices given by Licensor to you will be given by email or by conventional mail. Notices will be sent to the email address or mailing
address you provide Licensor as part of the registration process, or to updated addresses which you provide Licensor by notice
given consistent with this provision. Notices given by you to Licensor must be given by email and addressed to legal@mindbleeders.com, by
conventional mail sent to MindBleeders.com, Inc., Attn: Legal Department, 999 33rd Avenue, New York, or by telecopied
letter sent to 1-234-567-8910, Attn: Legal Department, or such updated addresses which Licensor may provide you by notice given consistent
with this provision.
| this first example... |
second example | this second example... |
|
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. |
See Also | Effective Notice
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
Information item name: | Contract Period or Duration |
Short description: | Commencement, duration and expiration of the contract |
Relevant contract
types: | ALL |
Optional or Mandatory in that type? | Optional - if a contract is silent on
duration, the law will imply a "reasonable time" |
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
or perpetual or unspecified |
- 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
- Need "period or duration of operation" at clause level as well
|
See Also | Termination
Contract Renewal
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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? |
See Also | Contract Duration
A Notice
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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
|
See Also | Contract Duration
A Notice
Obligations Which Survive Termination
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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) |
See Also | Termination
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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) |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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) |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
Information item name: | Contract Event |
Short description: | An action-based or time-based event which may occur during the life of the contract.
When a Contract Event occurs, there is a "state change" which affects the parties. |
Relevant contract
types: | (ALL or ..) |
Optional or Mandatory in that type? | (choose) |
Why capture this? |
- Search?
- Management of this contract? Yes, a Contract Event causes a "state change"
|
Characteristics to capture |
The event | eg notice received, goods delivered, specified date reached,
specified time period elapsed |
Notes | (insert note) |
See Also | A Notice
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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, 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'
|
See Also | Outcome
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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. 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.
|
See Also | Obligation/Permission/Prohibition
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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". |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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) |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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) |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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? |
See Also | Example Item 1
Example Item 2
|
Example Clauses/Articles |
Text of clause (or link) | Commentary |
first example | this first example... |
second example | this second example... |
|
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]. |