Environment:
Skip to main content
This documentation is in BETA version, for any information contact us at api@sibill.it

Common Terms

You might feel overwhelmed by the amount of information you can find in this documentation. That is why we recommend starting by learning what we are talking about: we think you need to get familiar with the terms used by the Sibill API as a first step.

In this section you will find the common terminology used throughout the documentation. The terms are also listed in Italian because you will often find them in API names and parameter names.

At the end of this guide you will find a diagram that illustrates the relationship between the different resources described in the documentation.

๐Ÿ™โ€โ™‚๏ธ User (Utente)โ€‹

The individual user who can access the web application. A user can have access to multiple companies.

๐Ÿข Company (Azienda)โ€‹

A company is the central entity in Sibill: all subsequent resources are owned by a company. For this reason, it will often be necessary to specify which company to work on when using our APIs. A company has at least one user who can access its resources.

๐Ÿ“„ Document (Documento)โ€‹

A document is a generic representation of content that can be an invoice, an order, a quote, etc.

๐Ÿ‘ฅ Counterpart (Controparte)โ€‹

A counterpart is a subject to whom a document or a flow is addressed. A counterpart can be a customer or a supplier.

๐Ÿงพ Invoice (Fattura)โ€‹

An invoice is a fiscal and accounting document that proves the sale of goods or the provision of a service. In this context, an invoice refers to a document that complies with the format of the electronic invoice.

โฐ Flow (Scadenza)โ€‹

A flow represents the conditions related to the methods, deadlines and status of a payment linked to a document.

๐Ÿฆ Account (Conto)โ€‹

A bank account is a contract with a bank or financial institution that allows depositing, withdrawing and managing money. In Sibill, a bank account is represented as an object that stores important data such as the accounting balance, the available balance and the related transactions.

๐Ÿ’ฐ Transaction (Transazione)โ€‹

An exchange between two or more parties of one or more goods, services, or financial assets on the market.

๐Ÿ”„ Reconciliation (Riconciliazione)โ€‹

Reconciliation is the process of verifying and matching your financial records, such as bank statements, with your internal accounting. In essence, it is about explaining and confirming the "why" behind each transaction, making sure your records accurately reflect your financial activity, whether it involves bank transactions or cash operations.

๐Ÿท๏ธ Category (Categoria)โ€‹

Represents a grouping of similar things under a criterion created by the user.

๐Ÿท๏ธ Subcategory (Sottocategoria)โ€‹

Represents a sub-grouping of similar things under a criterion created by the user that refers to a category.

Domain Model

The high-level relationship between the different resources can be visualized as follows:

In the Sibill system, the company (COMPANY) is one of the main entities. All other information revolves around it. Each company has linked bank accounts (ACCOUNT), documents (DOCUMENT) such as invoices, quotes or orders, and counterparts (COUNTERPART).

Documents, especially invoices, contain financial information and often include payment deadlines (FLOW). An invoice, for example, can have multiple flows if it involves instalment payments. Each flow indicates when, how much, and in what way the payment must be made.

Meanwhile, transactions (TRANSACTION) occur on the company's accounts โ€” money movements in or out: received payments, wire transfers, debits, etc.

This is where reconciliation (RECONCILIATION) comes into play. This is the process by which the system (or the user) links real transactions to the expected flows in the documents. In other words, it is used to understand whether a certain payment has actually taken place, on what date, for what amount, and which invoice (or part of it) it corresponds to.

This link is not always one-to-one: a transaction can cover multiple flows, and a flow can be paid with multiple transactions. That is why reconciliation has a "many-to-many" relationship with both flows and transactions.