Invoice posting and reconciliation

When you approve an invoice in Financica, the system creates a journal entry -- a transaction that records the invoice in your books. This page explains how that process works, how journal entries interact with bank transactions, and how to handle edge cases like currency mismatches.

Approving an invoice

Approving an expense (or posting a revenue invoice) creates a new transaction with legs derived from the invoice content:

• A control leg on the Accounts Payable or Accounts Receivable account, representing the obligation to pay or be paid.
• One or more category legs on expense or income accounts, one per line item.
• If the invoice has VAT, additional legs for the relevant VAT accounts (input VAT, reverse charge, etc.).

All legs are created in the invoice's currency. The amounts come from the invoice line items and totals, so the journal entry is a faithful accounting representation of what the invoice says.

This transaction is called the posted transaction and is linked to the invoice via the "posted transaction" field.

Linking a bank transaction as payment

Separately from approval, you can link a bank transaction to an invoice as a payment. This records that money actually moved to settle the invoice.

When you link a payment, Financica:

1. Reclassifies the bank transaction's category leg to point at the Accounts Payable (or Receivable) account, locking it as an invoice payment.
2. If only part of the transaction covers this invoice, splits the leg so the remainder stays editable.
3. Creates a payment application record that tracks the amount applied.

At this point you have two transactions in your books: the journal entry from approval and the bank transaction from the payment link. Both are correct and your books balance. The journal entry records the invoice content and the bank transaction records the actual payment; the payment application links them so each document's balance is tracked.

Recording a payment without a bank transaction

Sometimes the payment that settles an invoice has no matching imported bank transaction:

• The expense was paid in cash.
• A SaaS invoice was paid with prepaid credits (AWS credits, gift card balances, etc.).
• A small remainder was forgiven without a credit note (e.g. a €0.51 difference between the invoice and the round-number bank transfer).

For these cases, open the invoice's Linked payments card, click the ... menu, and choose Record a payment manually. The modal asks for an amount, a "paid from" account, a date, and an optional description; on submit it creates a two-leg transaction (chosen account ↔ Accounts Payable / Receivable) and links it to the invoice in one step.

Choosing the "paid from" account

The picker shows every account in the same currency as the invoice. Pick the account that reflects where the money actually came from:

• Cash on hand / Petty cash for cash payments.
• A custom asset account like AWS Credits for non-cash credits. Create the account in Chart of accounts first if you do not already have one.
• A P&L account such as Cash discounts on purchases (BE PCMN 657) or Other operating income for a write-off / round-down. The applied amount on the invoice is the same as a real payment; the difference lands in the P&L account you chose.
• A bank account if you intend to manually reconcile against an imported statement later. The picker flags bank accounts so you remember.

The funding account currency must match the invoice currency. Cross-currency manual payments (e.g. paying an EUR invoice from a USD wallet) are not supported in this flow yet; link a real bank transaction instead.

Unlinking a manually recorded payment

Manual entries appear in the linked-payments table with a Manual entry label. When you click Unlink on one, Financica asks whether to keep the underlying transaction in your books (just remove the link) or also delete the transaction (full undo). Imported bank transactions never offer this choice: they are owned by your bank-statement source, not by the invoice link.

Writing off a small payment difference

When an invoice is essentially settled but the payment was slightly off — €999 arrived on a €1,000 invoice, or €1,001 — the leftover keeps the invoice Partially paid or Overpaid even though nobody will ever move that euro. Financica detects this and shows a banner at the top of the invoice:

It looks like this invoice was underpaid by €1.00. Write off €1.00

Clicking the button shows a confirmation and then posts a small balancing entry between Accounts Payable/Receivable and a dedicated Payment differences account (BE PCMN 657 range, created automatically the first time). The entry is dated at the last payment on the invoice so it lands in the same period, VAT is untouched, and the invoice flips to Paid.

A few things to know:

• The banner only appears for small differences — up to 4% of the invoice total, and always for anything up to 1.00 in the invoice currency. A larger gap usually means a payment is genuinely missing, so it never gets a one-click write-off.
• It works in both directions (underpaid and overpaid) and on both bills and revenue invoices.
• If you intend to chase the missing amount or refund the surplus instead, dismiss the banner with the X; it stays hidden unless the outstanding difference changes.
• Foreign-currency invoices keep the manual flow described above.

Overpaying an invoice

Sometimes the bank transaction that settles an invoice is larger than the invoice itself. The most common reason is a prepayment that overshoots the final amount: a supplier asks for a deposit, you pay more than the invoice eventually turns out to require, and the difference is owed back to you.

When you click Link on a transaction whose remaining amount is larger than the invoice's balance due, Financica asks how to split it:

• Apply the balance due (partial) records the linked amount up to the invoice total. The unused remainder of the transaction stays available for linking elsewhere. This is the right choice when only part of the transaction belongs to this invoice (e.g. a single bank transfer paid two invoices).
• Apply the full transaction (overpayment) links the entire amount, marking the invoice as Overpaid with a negative balance due. This is the right choice when the supplier really did receive more than the invoice asked for and you expect them to refund the surplus.

Both choices are valid accounting; the prompt exists so the ledger reflects what actually happened with the money rather than silently rounding the link down to the invoice total.

Refunding an overpayment

When an invoice is in the Overpaid state, Financica unlocks the ability to link a refund transaction (an opposite-direction movement) to the same invoice. For an expense, this is money coming back from the supplier; for a revenue invoice, it is money going back out to the customer.

To settle the overpayment:

1. Open the invoice and click Search transactions.
2. Find the refund in the list. It is tagged with a Refund badge so you can tell it apart from regular payments.
3. Click Link. The application is recorded as a negative amount, so the invoice's applied total drops back to the invoice total and the balance due returns to zero.

You can only link a refund up to the current overpayment. If the refund is larger than the surplus (e.g. the supplier sent you back more than you overpaid by), Financica refuses the link and surfaces the remaining capacity in the error message; the surplus likely belongs against a different invoice or to its own credit note.

Refunds vs credit notes

A refund link is the right tool when the supplier or customer simply moved money back without producing a new document. If the supplier issued a formal credit note instead, post it as a credit note in Financica and use the Credit reconciliation panel to apply it (see Credit notes). The two paths produce equivalent ledger results but preserve the document trail in different places: link a transaction when it represents a cash movement, post a credit note when it represents a document.

How a linked payment reconciles

When you link a bank transaction to an invoice as payment, Financica does not merge it with the approval journal entry. Instead it reclassifies the bank transaction's category leg onto the Accounts Payable (or Receivable) control account and locks that leg as an invoice payment:

• The bank leg still records where the money moved.
• The reclassified control leg settles the invoice's open balance through a payment application, which is what drives balance_due.
• If only part of the transaction belongs to this invoice, the leg is split so the remainder stays editable and can be linked elsewhere.

Both the journal entry and the bank transaction stay in your transactions list. This is normal and your books are correct: the journal entry records the invoice content (expense/income accounts and VAT) and the bank transaction records the actual cash movement. The payment application links them so each document's balance is tracked.

Unlinking reverses this cleanly: the reclassification and any split are undone, the leg returns to its original state, and the payment application is removed (see Unlinking a payment below).

Multi-currency payments

When you pay an invoice in one currency from a bank account in another currency (for example, paying a USD invoice from a EUR bank account via Wise), the bank transaction typically has:

• A bank leg in the bank currency (EUR).
• Exchange legs converting between currencies.
• A fee leg for any transfer fees.
• A category/payable leg in the invoice currency (USD).

The journal entry, created during approval, has legs entirely in the invoice currency (USD). The control leg on the bank transaction settles the invoice's USD balance; the bank, exchange, and fee legs keep the cross-currency movement correct. The two transactions remain separate, which is the correct accounting treatment for a cross-currency payment.

Settling a foreign-currency invoice with a payment in your own currency

Often the conversion happens before the money reaches your account: a 10.10 GBP invoice is charged as 11.61 EUR by your card provider, and your bank statement only shows the EUR amount. In that case there is no GBP transaction to link at all.

For invoices in a currency other than your organization's, the Link to a transaction search also shows transactions in your own currency, and the suggestion uses the European Central Bank reference rate to find the likely match (a 10.10 GBP invoice will suggest a EUR transaction of roughly the converted amount).

Linking such a transaction opens a confirmation step showing both amounts, the implied exchange rate, and how it compares to the ECB reference rate:

• Within a few percent of the reference rate (normal card and bank conversion spreads): confirm with one click.
• Far from the reference rate: Financica warns you that the transaction does not look like a payment for this invoice, and spells out what will happen if you proceed anyway. You can adjust either amount -- for example, use only 90 EUR of a 300 EUR transaction that paid several invoices at once (the rest stays available to link to the other invoices), or apply the full amount and leave the invoice partially paid or overpaid.

On confirmation, Financica settles the invoice for the invoice-currency amount, consumes the chosen amount of the transaction, and automatically books the difference between the ECB reference value and what you actually paid as a realized exchange gain or loss (Belgian PCMN accounts 7540 / 6540, created for you on first use). Unlinking the payment removes the exchange-difference entry again, so the operation is fully reversible.

For currencies without a published ECB reference rate, the settlement is recorded at the rate implied by the two amounts and no exchange difference is booked.

Removing approval

If the journal entry was created incorrectly -- for example, with the wrong currency, the wrong accounts, or stale data -- you can remove the approval to delete the journal entry and start fresh.

From the expense detail page, open the ... menu and select Remove approval. This:

1. Deletes the journal entry transaction.
2. Returns the expense to "Needs review" status.

After removing approval, you can correct the invoice details and re-approve to generate a fresh journal entry. Any existing payment links to bank transactions are preserved -- only the journal entry is affected.

When to use Remove approval vs. Void

• Remove approval deletes the journal entry and lets you re-approve. Use this when the posting was wrong and you want to fix it.
• Void marks the entire invoice as void and removes the journal entry. Use this when the invoice itself should not exist in your books (e.g., it was a duplicate or was cancelled by the supplier).

Unlinking a payment

Unlinking a bank transaction from an invoice reverses the payment link:

1. The payment application record is deleted.
2. Any leg reclassification or splits are reversed, restoring the bank transaction's original legs.

The invoice returns to unpaid (or partially paid if other payments remain). You can then re-link a different transaction or the same one.

Credit note netting

When a credit note is applied against an invoice, the ledger records a second transaction alongside the credit note's own posting: the netting entry. This section explains why two transactions appear and how they relate.

Why two transactions?

A credit note's posting and its application to an invoice are two independent economic events:

1. The posting records that the credit note exists and reduces your liability. It is meaningful on its own — the credit note could later be applied to a different invoice, applied partially, or simply held. The posting creates the ledger entry that tracks the credit note's own balance.

2. The netting entry records the decision to offset a specific amount of the credit against a specific invoice. It closes out the invoice's open balance and consumes the corresponding portion of the credit note's balance.

Collapsing them into one transaction would be incorrect in the general case: a credit note applied in two partial amounts against two different invoices would require the posting and both applications to coexist as separate entries. The two-transaction design handles this naturally.

What the netting entry looks like

The netting entry has two legs, both on the same AP/AR control account:

Both legs are on Accounts Payable — this is correct. The transaction is not moving money; it is linking two opposing sub-ledger balances and netting them out. Each leg is linked to its respective document via invoice_payment_applications, which is how balance_due is derived for both documents.

The net effect on the Accounts Payable account balance is zero. What changes is each document's individual balance.

In the UI

The netting entry appears in the Linked transactions section of both documents, labelled "Credit note settlement". It does not have an Unlink button — to reverse a credit application, use the Remove button in the credit note's Credit reconciliation panel, which reverses the netting entry and restores both documents' balances cleanly.

The Application history in the Credit reconciliation panel and the "Credit note settlement" row in Linked transactions represent the same financial event viewed from two angles. The application history is the reconciliation record; the linked transaction is the corresponding journal entry.

Stripe-imported invoices

Stripe invoices are synced from the connected Stripe account. Financica's ledger — not Stripe — is the source of truth for whether an invoice is paid. balance_due is computed exclusively from invoice_payment_applications, so every reduction in the displayed balance is backed by a real journal entry.

Regular Stripe payments

When Stripe reports an invoice as paid and a matching bank/balance transaction has been imported, the sync auto-links it to the invoice. The linked transaction appears under Linked transactions and balance_due is updated through the normal reconciliation trigger.

If a credit note was issued against the invoice in Stripe, the netting entry is applied first and covers part of the total; the remaining Stripe bank payment auto-links for the remainder. Before this fix, the auto-link path would bail as soon as any credit note netting existed, leaving a phantom gap in Linked transactions. This is no longer the case.

Invoices marked as paid out of band

Stripe's dashboard has a Mark as paid action for invoices that were settled outside Stripe (bank transfer, cash, cheque, etc.). When an invoice is finalised this way, Stripe reports paid_out_of_band: true on the invoice but never produces a balance transaction. Without special handling, there is no ledger entry to match the payment.

For these invoices, the sync creates a synthetic pending transaction against the Stripe External Payments clearing account:

• For outbound invoices (AR): Accounts Receivable is debited (the obligation is reduced) and Stripe External Payments is credited (recording that cash arrived somewhere we have not yet identified).
• For inbound invoices (AP): Stripe External Payments is debited and Accounts Payable is credited.

The clearing leg is linked to the invoice via invoice_payment_applications, so balance_due reaches zero through the reconciliation trigger — not through a direct write from the Stripe sync.

Because the synthetic transaction is created as pending, it is clearly marked as awaiting confirmation. To close the loop, find the real bank deposit in your imported transactions and categorise it against Stripe External Payments; this clears the clearing account and the pending flag is removed.

Troubleshooting

The invoice still shows two separate transactions

This is expected. The approval journal entry and the linked bank transaction always remain separate; the payment application links them and settles the balance. Both transactions are valid and your books balance correctly. No action is needed.

The journal entry has the wrong currency or accounts

Use Remove approval from the expense menu to delete the journal entry, then correct the invoice details (currency, line items, accounts) and re-approve.

A payment is not reflected after re-approval

Linking a payment and approving an invoice are independent actions. If you removed approval and re-approved, check that the payment is still linked under Linked payments. If the balance looks wrong, unlink and re-link the payment to recompute the application.