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:
12 main concepts are grouped into 4 categories:
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:
It represents any source or supply from which benefit is produced.
(Learn how to calculate the net income from a resource)
It defines any resource owned by a business. Typically when we'll extend this class we'll find Products owned by the company.
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.
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.
- Obligation to pay:
- Obligation to deliver:
It represents a responsibility, usually a financial one. The class Liability is actually equivalent to the class gist:Commitment.
a Purchase will trigger an Obligation to pay that will be assigned to the buyer.
A Purchase will trigger an Obligation to deliver that will be assigned to the seller.
It represents something that happens in a point of time or a period of time. It's the actual
All the subclasses are : Offer, Negociation, Purchase, Transaction, Movement, Transfer, Acquirement, Allocation. (Read more)
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.
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.
It defines a document that presents information in an organized format for a specific audience and purpose.
It defines an official or approved report.
It defines a specific statement that is related to the accounting or financial part of a company.
- 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.
- 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.
- 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.
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 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 Requirements, that are the rules followed by the Transactions. Finally, keep in mind that the FinancialRecognition will produce and/or affect some Derived Data.
- DerivedData and FinancialSatement
- 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
- 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
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.
It defines all the raw data that are not the result of any calculation.
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 below visualisation summarizes the involved classes for a Financial Statement with their predicates.
A deeper dive in Transaction
FinancialRecognition is equivalent to a Collection of Transaction (mostly Allocation)
The following table is listing some basic accounting principles with their respective upper classes.
|Accounting principle||Upper classe|
|Income Statement (Profit & Loss)||FinancialStatement|
|Cash Flow Statement||FinancialStatement|
|Cost of Goods Sold||Derived Magnitude|
|Gross Profit||Derived Magnitude|
|Salaries and Benefits||Derived Magnitude|
|Rent and Overhead||Derived Magnitude|
|Depreciation & Amortization||Derived Magnitude|
|Earnings before Taxes||Derived Magnitude|
|Net earnings||Derived Magnitude|
|Account Receivable||Derived Magnitude|
Of course, the above list is non exhaustive, so there is no point to continue listing all possible examples.
|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: “Sell 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|
Again, the above list is almost endless, so there is no point here to continue listing all existing examples.
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,