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

Along with usage instructions for its various components:

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

ontology s parti

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.

Minimalist upper financial ontology

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.

An overview of the involved classes

Resource and Legal Entity:

overview of the ontology

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.

The interesting case of an employee

In the above diagram, it is obvious why an employee is considered and inferred to be a resource and a legal entity (as person).


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 in the ontology

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 in the ontology

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.

    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.


    overview of the ontology

    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.


    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.


    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:

    Deliverable in the ontology
    • 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.
    • 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.
    • Report in the ontology
    • 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.
    • 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.
    • Statement in the ontology
    • 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​.
    • A FinancialStatement is a particular ​Statement ​that is related to the financial ​Data​.
      FinancialStatement in the ontology
      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.


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

    This is what a Financial Statement is made of.

    A deeper dive in Transaction

    Financial Recognition:

    Transaction of the ontology

    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​.


    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 littleTransaction (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.


    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,

    Semantic Logo