Invoice posting and reconciliation | Financica Docs

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:

Reclassifies the bank transaction's category leg to point at the Accounts Payable (or Receivable) account, locking it as an invoice payment.
If only part of the transaction covers this invoice, splits the leg so the remainder stays editable.
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, but ideally they would be one transaction.

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.

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:

Open the invoice and click Search transactions.
Find the refund in the list. It is tagged with a Refund badge so you can tell it apart from regular payments.
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.

Transaction consolidation

When both conditions are met -- the invoice is approved (has a journal entry) and a bank transaction is linked as payment -- Financica attempts to consolidate them into a single transaction.

Consolidation takes the bank transaction's legs (the bank movement, fees, exchange legs) and the journal entry's legs (the invoice breakdown into expense/income accounts and VAT) and combines them into one transaction. The original journal entry is marked as replaced.

This produces the cleanest result: one transaction in your books that shows both where the money came from (the bank account) and where it went (the expense/income accounts from the invoice).

When consolidation succeeds

Consolidation works when the legs from both transactions can be combined into a balanced set. The typical case is:

A bank transaction with a bank leg and a category leg in the same currency as the invoice.
An invoice journal entry with a control leg and category legs, also in the invoice currency.

The consolidated transaction replaces the category leg from the bank import with the detailed breakdown from the invoice.

When consolidation does not happen

Consolidation is skipped (and both transactions remain separate) when:

Currency mismatch: The bank account currency differs from the invoice currency. For example, paying a USD invoice from a EUR bank account. The bank transaction has EUR legs with exchange legs to convert to USD, but the journal entry has USD legs. Financica cannot combine these into a single balanced set because the invoice content legs (USD) do not match the bank leg currency (EUR).
Partial payments: Only part of the bank transaction covers the invoice.
Complex leg structures: The bank transaction has too many legs or currencies to consolidate cleanly.
Already consolidated: The journal entry was already merged with a different payment.

When consolidation is skipped, both transactions remain visible in your transactions list. This is normal and your books are still correct. The two transactions together represent the full picture: the journal entry records the invoice content and the bank transaction records the actual payment.

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).

Because the invoice content legs (USD) cannot be substituted into a transaction whose bank leg is in EUR without breaking the per-currency balance, consolidation is skipped. You will see two separate transactions, which is the correct accounting treatment for a cross-currency payment.

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:

Deletes the journal entry transaction.
Returns the expense to "Needs review" status.
If the journal entry had been consolidated with a bank transaction, reverses the consolidation first, restoring the bank transaction to its original state.

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:

The payment application record is deleted.
Any leg reclassification or splits are reversed, restoring the bank transaction's original legs.
If the journal entry had been consolidated into the bank transaction, the consolidation is reversed: the bank transaction gets its original legs back and the journal entry is restored as a separate transaction.

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:

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.
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:

Leg	Account	Direction	Purpose
Invoice leg	Accounts Payable	Debit (inbound)	Reduces the invoice's open payable to zero (or by the applied amount)
Credit note leg	Accounts Payable	Credit (inbound)	Consumes the applied amount from the credit note's balance

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; the two entries will consolidate and the pending flag will clear.

Troubleshooting

The bank transaction and journal entry were not consolidated

This is expected when the bank and invoice currencies differ, or when the payment is partial. Both transactions are valid and your books balance correctly. No action is needed.

If you expected consolidation to happen for a same-currency payment and it did not, check whether the bank transaction has an unusual leg structure (extra fees, multiple splits) that made the consolidation ambiguous.

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 linked payment was not consolidated after re-approval

Linking a payment and approving an invoice are independent actions. If you remove approval and re-approve, the system will attempt consolidation with any already-linked payment during the next payment application. If you have already linked the payment before re-approving, unlink and re-link the payment to trigger a fresh consolidation attempt.