Accounting schemes
The accounting schemes drive automatic posting. For each type of transaction (sale, purchase, payment received, payment, payroll), they specify which accounts and which journal to use. The result: no account is fixed in the software — everything adapts to your chart of accounts.
Overview
An accounting scheme is a translation rule: it tells Swifto, for a given event, which account to move and in which journal to record the entry. These are the rules that make automatic posting possible — without them, Swifto would not know where to post each amount.
What the scheme provides
- Automatic, reliable posting
- Accounts matched to your chart of accounts
- A consistent journal per transaction type
- No account entry required for every document
Target audience
- Accountant — setup of accounts and journals
- Finance manager — consistency checks
- Executive — understanding of the rules
The "brain" of posting
Every time a document is validated, Swifto looks up the schemes to build the entry. Editing a scheme changes the way an entire family of transactions is posted.
What the schemes are for
The great strength of the schemes: no account number is hard-coded in the software. Everything goes through the schemes. Your accounting is therefore entirely adaptable to your own chart of accounts — if your chart differs from the standard model, you only need to adjust the schemes, never the application.
One rule per case
Each event + role combination points to a specific account and journal.
Adaptable
You adjust the account used without depending on a software update.
Always up to date
A change to a scheme applies to entries generated afterwards.
The accounts designated by the schemes must exist in your chart of accounts. First add an account to the chart, then point the desired scheme to it.
Events & roles
A scheme links an event (the transaction type) and a role (the function of the line in the entry) to an account and a journal. The role indicates what the amount represents: the third party, the income, the expense, the VAT, the bank or the cash.
flowchart LR EV["Event
Sales invoice"]:::s --> R1["Role · Third party"]:::p EV --> R2["Role · Income"]:::p EV --> R3["Role · VAT"]:::p R1 --> C1["Account 411
Journal VE"]:::ok R2 --> C2["Account 701
Journal VE"]:::ok R3 --> C3["Account 4371
Journal VE"]:::ok classDef p fill:#f3f1ff,stroke:#7366fe,color:#1f1c3d; classDef s fill:#F1F5F9,stroke:#334155,color:#1E293B; classDef ok fill:#CFFAFE,stroke:#0891B2,color:#155E75;
Events
Sales invoice, Purchase invoice, Customer payment received, Supplier payment, Payroll.
Roles
Third party, Income, Expense, VAT, Bank, Cash… — the function of the line in the entry.
Edit a scheme
The list of schemes is provided ready to use: on this screen, you neither create nor delete any. You only adjust, for each line, the account, the journal and its active status. That's enough to adapt all posting to your chart of accounts.
Edit the scheme
| Field | Role |
|---|---|
| Event | The transaction type concerned (not editable — part of the provided scheme). |
| Role | The function of the line: third party, income, expense, VAT, bank, cash. |
| Account | The account from the chart of accounts to use — this is what you adjust to your chart. |
| Journal | The journal in which the entry will be recorded. |
| Active | Enables or disables whether this line is applied. |
A change applies to entries generated afterwards; it does not recalculate entries already posted.
Scheme examples
Here are the standard schemes shipped with the module. They map each event to the usual accounts and journals of the Tunisian chart of accounts.
| Event | Role → account | Journal |
|---|---|---|
| Sales invoice | Third party = 411 · Income = 701 · VAT = 4371 | VE |
| Purchase invoice | Third party = 401 · Expense = 601 · VAT = 4366 | AC |
| Customer payment received | Bank = 532 / Cash = 541 · Third party = 411 | BQ / CA |
| Supplier payment | Third party = 401 · Bank = 532 / Cash = 541 | BQ / CA |
| Payroll | Personnel & social security accounts | PA |
These values are starting points: if your chart uses different numbers (for example a separate sales account per activity), point the scheme to your own account.
Business rules
Have your accountant validate the schemes — the associated accounts and journals must be checked before your first closing; it is the foundation of all posting.
An unconfigured role blocks the flow — if a role required for an event has no account, that transaction cannot be posted; Swifto flags it so you can complete the scheme.
Reuse existing accounts — point the schemes to accounts already present in your chart rather than multiplying new ones.
No fixed account — every account number used in posting comes from a scheme, so it remains editable at any time.
FAQ & Tips
Can I change the account used for my sales?
Yes: open the "Sales invoice" scheme and point the Income role to the account of your choice. Future invoices will use that account.
What happens if a scheme is not filled in?
The transaction concerned is not posted, and Swifto prompts you to set up the missing account. Complete the scheme to unblock the flow.
Do changes apply retroactively?
No: an edited scheme does not recalculate entries already generated. It applies to transactions posted after the change.
Tip — check your schemes before the first closing
Review each event with your accountant: getting the scheme right from the start saves you reversing-entry corrections later.
