Clearing, FX Gain/Loss, and CTA

Clearing (matching) transactions and recording foreign exchange impacts are critical accounting processes. This article explains how clearing works, how FX gains and losses are recorded, and how cumulative translation adjustment (CTA) is handled. For a short overview, see How Light handles FX.

# What is this page about

This page covers what happens when you match a payment to an invoice: how clearing links entries, how Light calculates a realised FX gain or loss against the original posting rate, when a CTA adjustment arises, and how automatic matching picks its candidates. Read it if you settle invoices in a currency other than your entity's own.

On this page

• Clearing Explained
• Clearing Workflow
• Partial Clearing
• Clearing with FX Adjustments
• Why a paid invoice can still show a balance
• Realised vs. Unrealised FX Gains and Losses
• FX Clearing Entry
• CTA (Cumulative Translation Adjustment)
• Reversing a Clearing
• Clearing Discrepancies
• Automatic Clearing
• Best Practices
• Related Articles

# Clearing Explained

Clearing is matching two GL entries to show they've been settled:

AP Example:

• Invoice Payable posts: Debit Expense, Credit AP
• When paid, Payment posts: Debit AP, Credit Cash
• Both are matched/cleared to show the invoice has been paid

AR Example:

• Invoice Receivable posts: Debit AR, Credit Sales
• When customer pays, Payment posts: Debit Cash, Credit AR
• Both matched/cleared to show the invoice has been collected

Clearing links the entries without modifying them, so both remain as originally posted.

# Clearing Workflow

Typical clearing process:

1. Transaction posts: the document creates GL entries
2. Clearing happens: a second entry matches the first
3. Both marked cleared: Light shows they have been matched
4. Audit trail: records who cleared them and when

For example:

• Invoice created and posted to GL
• Bank processes payment
• User matches invoice to payment (manually or auto)
• Both marked as cleared

# Partial Clearing

When amounts don't match exactly:

Scenario:

• Invoice for $10,000
• Two partial payments: $7,000 and $3,000

Clearing:

1. First payment clears $7,000 of the invoice
2. Invoice status becomes "Partially Cleared"
3. Second payment clears remaining $3,000
4. Invoice status becomes "Cleared"

GL shows all three entries linked together.

# Clearing with FX Adjustments

When clearing involves FX differences:

Scenario:

• AR Invoice posted: 100,000 EUR at rate 1.20 = 120,000 USD
• Customer payment received: 100,000 EUR at rate 1.18 = 118,000 USD
• FX loss: 2,000 USD

GL entries:

1. Invoice posts: Debit AR $120,000, Credit Sales $120,000
2. Payment received: Debit Cash $118,000, Credit AR $118,000
3. Clearing posts an FX adjustment automatically: Debit FX loss $2,000, Credit AR $2,000
4. AR for this invoice is now zero, and the invoice and payment are cleared

The realised FX gain or loss is calculated against the rate on each document's own valuation date - normally its posting date, though a different rate date can be set explicitly on a document. Any period-end revaluation booked in the meantime uses the separate unrealised FX gain/loss account and does not change the realised amount recognised at clearing.

Note: if you reset a posted invoice or payment and re-date it before it clears, its valuation date moves along with the new posting date (unless a different rate date is set explicitly on the update). Because clearing compares each document's own valuation date, re-dating a document this way can change the size of the realised FX/CTA recognised when it's later cleared - or eliminate it entirely if both sides end up valued on the same date.

# Why a paid invoice can still show a balance

If a month-end revaluation ran between the invoice and the payment, a small balance stays on the AR or AP account after the invoice is paid.

Scenario:

• 1 January: AR invoice posted for 100,000 EUR at 1.20 = 120,000 USD
• 31 January: the month-end revaluation at 1.18 posts an unrealised loss of 2,000 USD, so AR for this invoice is 118,000 USD
• 10 February: the customer pays 100,000 EUR at 1.19 = 119,000 USD. Light clears the invoice and posts a realised loss of 1,000 USD against the original 120,000 USD

The invoice is fully paid, but January's 2,000 USD revaluation is still on the AR account. The AR balance and the aged receivables report show it against this customer.

When you run the FX revaluation for February, Light includes the invoices and bills that were fully paid in February and reverses their earlier revaluations. The 2,000 USD comes off AR and the balance for this invoice is zero. Across the two months, the P&L shows a total loss of 1,000 USD, which is the realised loss.

The same applies to bills and AP. See FX revaluations for how the month-end run works.

# Realised vs. Unrealised FX Gains and Losses

Unrealised FX gain or loss

• Occurs when an unpaid foreign currency item is revalued at month-end
• Example: AR in EUR revalues due to a rate change
• Posted to the unrealised FX gain/loss account in the P&L
• Updated at each month-end, and reversed by the month-end run after the item is paid

Realised FX gain or loss

• Occurs when a foreign currency transaction finally settles
• Example: you receive EUR cash at a different rate from the invoice posting
• Final, actual gain or loss
• Not reversed, because it has been realised

Most FX transactions have both an unrealised component during the holding period and a realised component at settlement.

# FX Clearing Entry

Note: this section describes clearing when a foreign currency (or FX) difference exists. A same-currency clearing with no FX difference doesn't create any new ledger transaction. It only records that the two entries are cleared against each other.

When clearing foreign currency items:

Payment entry:

• Debit/Credit: Cash account (actual amount received or paid)
• Debit/Credit: AR/AP account (at the payment-date rate)

FX adjustment entry (posted automatically with the clearing):

• Debit: FX loss account, or Credit: FX gain account (the difference vs. the original posting rate)
• Offsetting line on the AR/AP account

The FX adjustment is a separate ledger transaction linked to the clearing event, so together the entries record:

• How much cash actually came in or went out
• The FX impact vs. original posting
• The cleared status of the documents

Small rounding differences from converting between transaction, local, and group currency go to a rounding account.

# CTA (Cumulative Translation Adjustment)

CTA captures translation differences between an entity's local (functional) currency and the group (presentation) currency. When an item is paid, the local-to-group rate may also have moved since it was posted. Light posts the part of the group-currency difference that the local FX gain or loss doesn't cover to CTA.

Scenario:

• An invoice and its payment clear with a given FX difference in local currency
• The local-to-group rate moved between posting and clearing
• The remaining group-currency difference is posted to CTA

GL entry for CTA:

• Debit/Credit: Currency translation adjustment account (system account)
• Offsetting line on the AR/AP account

A CTA line has a zero local-currency amount, because it only changes the group-currency balance. For CTA posted at month-end, see FX revaluations.

# Reversing a Clearing

If documents were cleared in error, the clearing can be reversed:

• Reversing a clearing also reverses the FX and CTA adjustment transactions that were posted with it
• The cleared documents return to Posted (or stay Partially cleared if other clearings remain)
• The original entries are never modified, since reversals are posted as offsetting transactions, preserving the audit trail

# Clearing Discrepancies

Sometimes clearing amounts don't match:

Possible reasons:

• Bank fees reduced payment
• Rounding differences
• Partial payment
• Data entry error

Resolution:

1. Identify reason for discrepancy
2. For bank fees, select Bank fees as the deviation reason, and Light creates a Bank fees journal entry for the difference
3. FX and rounding differences are calculated and posted automatically as part of the clearing
4. For partial payments, clear the matched amount, and the document stays Partially cleared until the remainder is settled

# Automatic Clearing

Light matches imported bank transactions to your posted documents using seven built-in rules. These are active from the moment you start using bank reconciliation, so there is nothing to switch on or set up.

Light tries the rules in order and takes the first one that produces a valid match:

1. Open sales invoice: reads the payer's reference or remittance information and matches it to an open sales invoice number. The invoice must be unambiguous, and the amount cannot exceed what is still owed. Incoming payments only
2. Open supplier bill: the same approach for a bill you are paying. Outgoing payments only
3. Card balance funding: recognises a transfer to one of your card balance accounts by its IBAN. Outgoing payments only
4. End-to-end ID: matches the payment's end-to-end reference from the bank file to an existing ledger entry, where the amounts must total exactly
5. Reference or document number: matches an extracted reference to a ledger entry's document number, at an exact amount
6. Amount and description: exact amount and matching description text, where only one candidate exists
7. Amount and date: exact amount on the same date, where only one candidate exists. This is the loosest rule, so Light tries it last

Any AI rules you create yourself run after all seven. Automatic matching relies on your bank transactions carrying parsed payment details and on the bank ledger account existing.

# Best Practices

• Match frequently: matching daily or weekly prevents large backlogs
• Document basis: note why amounts do not match exactly
• Monitor CTA: track the CTA balance for foreign operations
• Reconcile currencies: reconcile each currency separately
• Run revaluation monthly: this clears the leftover balance on paid invoices and bills

# Related Articles

• How Light handles FX
• FX revaluations
• Multi-currency reconciliation
• Multi-entity ledger management
• Automated bank reconciliation