Documentation

About the gist:Accounting and the applied semantics in OWL (Web Ontology Language).

Along with usage instructions for its various components:

PARTI

This visual presents the fundamental world wide concepts for any business model as a "yin-yang" symbol:

12 main concepts are grouped into 4 categories:

1. Resource
2. State
3. Event
4. Liability

Minimalist upper financial ontology

The following diagram explains how the gist accounting ontology works:

It takes the core business concepts (PARTI) and turn them into classes and predicates.

The boxes represent classes and the arrows between them represent predicates. Upper and subclasses are visible in the above diagram with colored boxes and “white” arrows.

To go from the concepts (PARTI) to the actual ontology, some positions have been taken to define what needs to become classes and what will be predicates. Many of the concepts have been turned into classes here. But what is important to notice is that we don’t have any “State” class that would define the previously defined ideas of “Ownership” and “Possession”. Those ideas resides now in the predicates associated with the ​Transaction classes.

As previously defined a ​Movement ​or ​Execution will ​discharge ​a ​Person (Legal Entity, above, ​Seller and ​Buyer​) ​from ​a ​Liability (above, ObligationToPay or ObligationToDeliver) in the sense of a change of possession. The same thing can be said about a ​Transfer that operates a change of ownership. But often there is a need to define both of those ideas at the same time, it is then doable through the class ​Acquirement that is a subclass of both ​Movement and Transfer​. Class Execution refers to the concept lying behind Movement but enables to take into accounting cases where there is no actual movement because it is for instance a Service that has been sold. As such the concept of a real Movement does not fit here but rather the Execution​ of the Service.

Going into details

An overview of the involved classes

Resource and Legal Entity:

Resource:

It represents any source or supply from which benefit is produced.
(Learn how to calculate the net income from a resource)

• Asset:

It defines any resource owned by a business. Typically when we'll extend this class we'll find Products owned by the company.

• Product:

It defines the result of a project within a company. The project might still be going on but "Product" refers indeed to the project version that is used in production.

Legal Entity:

A legal entity is any Entity that is an association, corporation, partnership, proprietorship, trust, or individual that has ​legal standing in the eyes of ​law.

• Agent:

An agent is a legal entity acting for another legal entity in a clearly specified capacity.

Requirement:

In the above minimalist upper ontology's diagram the concept of ​"Requirement" was introduced as the possible subject of an ​Offer​. Indeed, sometimes what is aim to be sold is not an existing real ​Resource but a future Service or Product that is then defined by a list of Requirements​.

Liability:

Obligation:

It represents a responsibility, usually a financial one. The class Liability is actually equivalent to the class ​gist:Commitment​.

• Obligation to pay:

a ​Purchase will ​trigger an ​Obligation to pay that will be assigned to​ the buyer.

• Obligation to deliver:

A ​Purchase will ​trigger an ​Obligation to ​deliver that will be ​assigned to​ the seller.

Event:

Event:

It represents something that happens in a point of time or a period of time. It's the actual ​gist:Event class.
All the subclasses are : Offer, Negociation, Purchase, Transaction, Movement, Transfer, Acquirement, Allocation. (Read more)

Note

Offer:

This class is defined already in GIST as a subclass of gist:ContingentObligation. For the purpose of gist:Accounting we make it also a subclass of Event.

A deeper dive

More financial specific classes

In this section some new classes are introduced in order to describe the data that are related to all the accounting parts of a company and all the documents that are produced from them.

Deliverable:

Deliverable:

It defines a tangible or intangible good or service produced as a result of a work that is intended to be delivered to a Legal entity.

• Report

It defines a document that presents information in an organized format for a specific audience and purpose.

• Statement

It defines an official or approved report.

• FinancialTransaction

It defines a specific statement that is related to the accounting or financial part of a company.

Scope:

It defines the accessibility of something. In our specific case, it defines the accessibility of a ​Report​. As such, Scope is equivalent to a ​Collection of ​Legal entities​. Some instances of this class could be “public”, “private” or “internal” for example.

Magnitude:

gist:Magnitude defines any kind of data. ​Data is a set of values of subjects with respect to qualitative or quantitative variables. ​Data and information or knowledge are often used interchangeably. We use the class gist:Magnitude here since all the data needed for accounting purpose are quantitative ones.

• SourceMagnitude

It defines all the raw data that are not the result of any calculation.

• DerivedMagnitude

It defines any data resulting from a calculation on a set of SourceMagnitude​.

In the following subsections we go deeper in the description of the above classes and how they relate to each other. In order to facilitate the understanding we go through the ​Deliverable class hierarchy from the ​Deliverable to ​FinancialStatement.​ It is important to keep in mind that, since each class is a subclass of the other, the relations defined for the parent class is defined for the child class as well.

As a result:

• The ​Deliverable conforms to a set of requirements.
  By the way the class ​gist:Requirement and the predicate ​gist:conformsTo that describe this relation are alredy well defined in the upper ontology.


• A ​Deliverable is also ​producedBy a ​LegalEntity that is usually a company and ​ownedBy another LegalEntity that is usually the client company. But as a result of an internal project, a ​Deliverable can be ​producedBy and ​ownedBy the same LegalEntity​.


• Finally, a ​Deliverable can be part of a bigger one. In that case a ​Deliverable can be ​requiredBy a company as part of a bigger contract. And as opposition some ​Deliverable have to be produced for the sake of the project yet not ​requiredBy​ anyone.

Report:

• A ​Report ​has a ​Scope ​(availableTo) that defines who can access it. This Scope is defined as a ​Collection of ​LegalEntity and as such it is equivalent to gist:Collection hasMember some LegalEntity.​ GIST is already providing the necessary class and predicate to express this.

• A ​Report is also usually ​basedOn a ​Template​.
  Again, GIST is already providing the predicate ​gist:basedOn and the class ​gist:Template​ for you. Notice the use of the predicate ​gist:baseOn and not ​gist:governedBy (as will be discussed in the next subsection) since a Report is not yet official.

Statement:

• A Statement is a ​report ​that is official. As such it can be ​basedOn a ​gist:Template​. A Statement ​contains some data that are ​Magnitude​. The ​Magnitude ​class from GIST has already been discussed above but we’ll go further on the ​DerivedMagnitude​ class.

• A ​DerivedMagnitude as its name tells ​derivedFrom some ​Magnitude​.
  The SourceMagnitude are used for the applied ​Derivation in order to obtain the ​DerivedMagnitude​. This ​Derivation is a subclass of ​​gist:Content since it is a Content, Text or Formated (usually a mathematical function), that describe how the ​DerivedMagnitude is obtained from the SourceMagnitude​.

FinancialStatement:

• A FinancialStatement is a particular ​Statement ​that is related to the financial ​Data​. As such it is defined on a period of time or a point in time. Both predicate ​gist:actualStart and ​gist:actualEnd enable to determine a period of time. If both predicates are pointing toward the same gist:TimeInstant then it is defining a point in time.
• As usual, the gist upper ontology is providing you all the necessary classes and predicates for any intended further model.

Summary:

The below visualisation summarizes the involved classes for a Financial Statement with their predicates.

This is what a Financial Statement is made of.

Transaction

A deeper dive in Transaction

Financial Recognition:

FinancialRecognition is​ equivalent to a Collection​ of ​Transaction​ (mostly ​Allocation​)

• The ​Template​ defines a schema for the set of ordered ​Transaction​.


• ​​Transaction​ generates some ​​Magnitude​ that are reflected in different parts of the system or modify some of it.
  
  For example: when selling a service to a customer, you might spread the amount of money paid by the client across multiple parts of the system like, a pourcentage attached to the travelling expenses, an other to the purchased material expenses, another part to the salary of the employee assigned to the task, and so on ... This idea is well defined here by linking an associated ​​FinancialRecognition​​ to the ​actual​ ​​​Transaction​​.


• Therefore, an actual ​​FinancialRecognition​ is defined as a ​​Collection​ of (atomic) ​​Transaction​​. Those “atomic” ​Transactions​ correspond to the repartition of the initial ​​Transaction​ elements throughout the different parts of the company accounting. A guess is that most of those “atomic/internal” ​Transactions​​ will actually be ​​Allocations​​.


• The ​​FinancialRecognition​ is ​​basedOn​ a ​​Template​ (specific to each company) and ​conformsTo​​ some ​​Requirement​s​, that are the rules followed by the Transactions. Finally, keep in mind that the ​​FinancialRecognition​ will ​​produce​ and/or ​​affect​ some Derived Data.

Some explanations

DerivedData and FinancialSatement

The following table is listing some basic accounting principles with their respective upper classes.

Accounting principle	Upper classe
Balance Sheet	FinancialStatement
Income Statement (Profit & Loss)	FinancialStatement
Cash Flow Statement	FinancialStatement
Revenue	Derived Magnitude
Cost of Goods Sold	Derived Magnitude
Gross Profit	Derived Magnitude
Expenses	Derived Magnitude
Salaries and Benefits	Derived Magnitude
Rent and Overhead	Derived Magnitude
Depreciation & Amortization	Derived Magnitude
Interest	Derived Magnitude
Earnings before Taxes	Derived Magnitude
Taxes	Derived Magnitude
Net earnings	Derived Magnitude
Assets	Derived Magnitude
Cash	Derived Magnitude
Account Receivable	Derived Magnitude
Inventory	Derived Magnitude

Of course, the above list is non exhaustive, so there is no point to continue listing all possible examples.

• Most of the classical examples are ​DerivedMagnitude that enables to generate some ​FinancialStatement that can then be used for a whole range of purposes.
• The interesting part now is to think about ​how and ​to which class should be linked the SourceMagnitude​ from which are derived the used ​DerivedMagnitude​.

Furthermore

About the transactions

Accounting common transactions	How to reflect it ?
Purchase something	This can be a more or less complicated process depending on the kind of thing that is purchased. However, most of the time, a process is defined for any purchase within a company, including where to reflect the money and goods movement, what paperwork to generate and so on... Those can be specified using ​Templates and Requirement​, then the ​DerivedMagnitude can directly be modified according to the associated derivation applied in the front end code.
Long term lease	Usually, those lease implies the actual lease refund and the interest. Therefore this Transaction correspond to at least 2 “atomic” Transactions that will ​affect then 2 different derived magnitudes (that will be reflected in different places in the ​Financial Statements​).
Pay for purchased item or payment on lease	This can be considered as an “atomic” Transaction of a bigger ​Transaction that correspond to item purchase in its entirety.
Sell project to a client	These kind of ​Transactions are usually complex. They can be defined in 2 ways, either like a big ​Transaction having multiple little ​Transaction (corresponding to each billing for instance), or directly like a set of Transaction​. Note that whatever the chosen solution is, the same above described ontology can be used.
Charge time to client project	That would correspond to a Transaction part of the bigger ​Transaction that is the above cell: “S​ell project to a client”​ . Whatever the chosen solution, those ​Transactions are usually defined by a set of ​Requirement​, specific to each company, and ​affect different derived magnitudes​. As such they are, in many ways, similar to the already explained “​Purchase something”​ ​Transaction​. It is a matter of point of view but the concept behind is the same, isn't it?
Incur Expenses (cc or employee reimbursement)
Bill client for fees
Bill client for expenses
Receive payment
Pay Employees

Again, the above list is almost endless, so there is no point here to continue listing all existing examples.

• Nevertheless, it becomes obvious now to see that most of the classical above applications fit in perfectly with the gist accounting ontology.
  The set of ​Requirement applies to reflect the ​Transaction on the ​Magnitude and the used ​Template​ for each ​Transaction​.
• The remaining task is simply about defining the set of ​Rules ​associated with each kind of ​Transaction​, and the ​Magnitude ​affected by each of them. When well defined and implemented, the gist accounting ontology enables you to trace back to the origin of each ​Transaction​, making it possible to know accurately the actual Cash flow.

Conclusion

The end of this Documentation

We remain at your disposal for any further details you might want to discuss and would be grateful if you let us know your current work. Best,