Posting

Posting is the step where a document becomes a journal entry. Simon generates the entries when the document is sufficiently qualified and reconciled; manual ODs remain possible for cases outside the document flow.

When a document is postable

A document is postable when the extracted data is validated, the third party is identified, the tax qualification is set and the payment method is known or reconciled. If an element is missing, the workflow keeps the document at the previous stage with an explicit block.

What you validate

You validate the proposed journal entry:

• journal;
• accounts;
• third party;
• amounts;
• VAT;
• label;
• attachment to the document.

You can approve it, reject it or correct the upstream data before relaunching the posting.

The principle: accounting by annotation

In a classic accounting software, a human reads the invoice, chooses the accounts, enters the amounts. In Simon, it is the annotation of the document that determines the journal entry. The flow is entirely mechanical:

flowchart TD
    A["Annotation"] --> B["Context"]
    B --> C["Rule selection"]
    C --> D["Template rendering"]
    D --> E["Journal entry"]

Each step enriches the previous one. Let’s look at them one by one.

---

1. The context: everything Simon knows about the document

When a document reaches posting, Simon builds a context by aggregating everything that has been collected at the previous steps:

Data	Source	Example
Net, VAT, gross amounts	Annotation (ingestion)	€1,000, €200, €1,200
Breakdown by VAT rate	Annotation	€800 at 20%, €200 at 5.5%
Accounting category	Annotation	fees, office supplies, IT equipment (fixed asset)
Third party (supplier/customer)	Annotation + third-party base	ACME Corp, SIREN 123456789
Deductibility rate	Qualification	100%, 50%, meal rate schedule
Recoverable VAT	Qualification	yes / no
Linked bank transaction	Reconciliation	Transfer of 15/01, €1,200
VAT regime	Tax configuration	Payments / Invoices
Geographic zone	Third-party address	Mainland France, Corsica, overseas departments, EU

The context is the contract between the annotation and the posting engine: if the input data is correct, the output entry will be correct.

---

2. Rule selection: which template for this document?

Simon has a library of templates (the structure of an entry) and mapping rules (the conditions that specialize a template). Selection works by specificity:

1. Simon filters the templates compatible with the document type (supplier invoice, customer invoice, bank transaction…)
2. For each template, it evaluates the rules whose conditions match the context
3. Each matched condition adds weight: a match on the accounting category is worth more than a match on the nature of the document
4. The rule with the highest score wins

Example: a supplier invoice with the category honoraires matches the “Fees” rule (which overrides the expense account to 6226) rather than the default rule (which uses 6061).

Astuce

This mechanism automatically handles special cases: a fixed-asset invoice, an intra-EU invoice with reverse charge, a credit note — each situation has its rule, selected by the conditions of the context.

---

3. Rendering: from template to entry

A template describes the structure of the entry: which lines, which accounts, which amounts, which conditions. The selected rule overrides certain accounts (for example, the expense account moves from 6061 to 6226 for fees).

Let’s take an ACME Corp supplier invoice of €1,000 net + €200 VAT:

Direction	Account	Amount	Label
Debit	6226	1,000.00	Purchase ACME Corp
Debit	44566	200.00	Deductible VAT 20%
Credit	401	1,200.00	Invoice INV-001

The account 6226 (fees) comes from the mapping rule. The accounts 44566 (deductible VAT) and 401 (suppliers) come from the template. The amounts come from the context.

---

4. The automatic transformations

After the base rendering, Simon applies transformations according to the context:

Multi-rate VAT

An invoice with lines at 20% and 5.5% produces separate expense and VAT lines per rate. Each line carries a tax tag for the CA3 breakdown.

Pro/personal proration

If the document is qualified at less than 100% deductibility (e.g. director’s phone at 50%), Simon automatically separates:

Direction	Account	Amount	Label
Debit	626	50.00	Telecom (pro share 50%)
Debit	455	50.00	Telecom (personal share 50%)
Debit	44566	10.00	Deductible VAT (pro share)
Credit	401	110.00	Invoice Orange

The personal share is charged to the shareholder current account (455). The VAT is only recoverable on the pro share.

Intra-EU reverse charge

For EU supplier invoices with reverse charge, Simon automatically generates a separate OD (deductible VAT / intra-EU VAT due), attached to the source invoice.

Currency conversion

Invoice in dollars or pounds? The amounts are converted at the day’s ECB rate. An embedded rate takes over if the API is unavailable.

Tax metadata

Each journal entry line receives invisible but essential tags for the returns: VAT rate, VAT on payments, geographic zone, type of VAT operation. It is these tags — not the account numbers — that feed the CA3 and the tax return package.

---

Root accounts, no custom chart

This is a strong design choice.

A traditional accounting software creates custom sub-accounts for each supplier or category: 6061001 for Amazon, 6061002 for Staples. The chart of accounts swells and becomes specific to the company.

Simon takes the opposite approach: the chart of accounts remains strictly the standard PCG (~840 accounts). No sub-account is created. Discrimination is done through the metadata of each journal entry line: third party, accounting category, VAT rate, geographic zone.

Why?

• The PCG is enough. The root accounts cover all cases. Sub-accounts are an organizational convention, not a legal obligation.
• The intelligence is in the metadata. The FEC, the CA3, the tax return package — all the returns are computed from the metadata, not from the account numbers.
• The chart stays readable. No 2,000-account chart, half of which are ad hoc sub-accounts.
• The analyses are richer. Filtering by third party, by category, by period — the metadata enables cross-tabulations that sub-accounts do not allow.

Note

Two supplies invoices (Amazon and Staples) go to the same account 6063. The distinction is made by the third party and the category attached to each line. The analytical views (general ledger, trial balance) filter by any dimension.

---

Automatic selection of the third-party account

The third-party account is determined by the context, not entered manually:

Situation	Account
Supplier invoice	401
Supplier invoice — fixed asset	404
Customer invoice	411
Paid by the director	455
Expense report (pending)	471

---

Batch processing

Simon processes all eligible documents in a single pass. Each entry receives an idempotency fingerprint (SHA256) that prevents duplicates in case of a rerun.

---

Approval and cancellation

Lifecycle of a journal entry

stateDiagram-v2
    [*] --> Proposed : Posting
    Proposed --> Approved : Approval
    Proposed --> Rejected : Rejection
    Approved --> Reversed : Cancellation

• Proposed — the entry is generated, pending validation
• Approved — validated. Automatic lettering is attempted (invoice ↔ payment). The child documents (linked ODs) are automatically promoted and posted in cascade.
• Rejected — discarded
• Reversed — a reverse entry is created. Preferred when tax returns have already been filed for the period.

---

Post-posting actions

Some documents trigger additional actions:

Trigger	Result
Fixed-asset invoice	Asset created + depreciation schedule generated
Intra-EU invoice with reverse charge	Reverse-charge OD generated and attached
Approved entry on a third-party account	Automatic lettering attempt (invoice ↔ payment)