Scenarios and outcomes

Residual handling

A residual is the leftover difference between the bank movement and the documents matched against it, defined as the transaction total minus the matched-document total (txTotal − docTotal). A positive residual means the bank received/paid more than the documents account for; a negative residual means less.

Example: a EUR 100.00 customer invoice is matched against an inbound EUR 99.00 transaction. That's a EUR 1.00 residual. If it's within your configured bank-fee tolerance, Atlar creates the payment for the full EUR 100.00 (applied to the invoice) plus a journal entry for the EUR 1.00 bank fee — the invoice is still settled in full, and the gap is explained automatically. The rest of this section explains the rule that produces that outcome for every kind of residual.

When a match is materialized, Atlar resolves the residual through a fixed precedence — each step only runs if the previous one has not already fully explained the gap.

Included transaction charges. If the bank reports charges that were deducted from the transaction (Charges flagged as INCLUDED), they are aggregated per transaction and booked as a journal entry against the GL account configured on the BANK_FEE posting rule. This represents fees the bank withheld from the gross amount, so the document can still be settled in full.

Charges are booked only when the gross residual (txTotal − docTotal, before charges) is non-zero. If the matched documents already total the settled amount — for example a source journal that itemizes the bank fee on its own GL lines — Atlar does not emit a second BANK_FEE journal.

Fixed-amount lines on ALWAYS creation templates are subtracted from the residual at this stage as well, so a known bank-currency fee on the template is not treated as an unexplained leftover later.
Residual-driven creation templates. Any residual still remaining is offered to creation templates triggered by its sign — ON_POSITIVE_RESIDUAL or ON_NEGATIVE_RESIDUAL. These let you explain the leftover with a configured document. The template's document type is constrained so cash cannot silently drift:
- A residual PAYMENT is only valid for an overpayment, and must not apply to the matched source documents. The surplus is left unapplied.
- A residual JOURNAL_ENTRY can absorb an under- or overpayment against a configured GL account. If the template applies to the matched source documents, the journal posts to AR/AP rather than the bank.
For non-manual matches, a residual template is only accepted when the leftover is within 10% of the transaction total. Manually created matches skip this cap.
Tolerance fallback. If no template handled the leftover, the residual (after charges and any fixed-amount ALWAYS-template lines) is checked against a posting rule. Classification is relative to the matched documents, not the residual's sign alone: more cash moved than the documents called for is an overpayment (customer over-receipt or vendor over-pay); less cash moved is a fee or write-down (customer under-receipt or vendor under-pay). The rule is accepted only if the residual is within that rule's ThresholdBasisPoints :

Tolerance fallback. If no template handled the leftover, the residual (after charges and any fixed-amount ALWAYS-template lines) is checked against a posting rule. Classification is relative to the matched documents, not the residual's sign alone: more cash moved than the documents called for is an overpayment (customer over-receipt or vendor over-pay); less cash moved is a fee or write-down (customer under-receipt or vendor under-pay). The rule is accepted only if the residual is within that rule's ThresholdBasisPoints:

`Cross-currency`	Classification	`Posting rule`	Outcome within threshold
`Yes`¹	`Positive`	`FX_GAIN`²	Accepted silently; no journal entry booked
`Yes`¹	`Negative`	`FX_LOSS`²	Accepted silently; no journal entry booked
No	More cash than the documents	`OVERPAYMENT`²	An unapplied payment is emitted against the matched counterparty (customer deposit or vendor prepayment)
No	Less cash than the documents	`BANK_FEE`	A balancing journal entry is booked against the rule's GL account

1. This row applies when Atlar itself derived the exchange rate. If the bank transaction directly supplied the rate, a leftover residual is instead treated as same-currency and routed to OVERPAYMENT or BANK_FEE above. The bank's own rate is trusted, so there is no separate FX gain/loss bucket.

2. Only BANK_FEE posts to a configured GL account. FX_GAIN, FX_LOSS, and OVERPAYMENT are threshold-only or counterparty-driven and do not require one.

The residual is checked against the rule's ThresholdBasisPoints, and only accepted if it's within that threshold — except for manually created matches, which bypass this threshold check entirely and rely on the creator's judgment instead. The same manual bypass applies to the 10% cap on residual-driven creation templates.

Hard failures. If the applicable posting rule is missing, or the residual exceeds the threshold, the match can't be materialized and is rejected at match-create time. Depending on what specifically failed, you'll see one of several validation errors (for example, an FX-threshold breach, a missing reconciliation-configuration rule, or — for transfers — unbalanced legs or an unresolved settlement currency). The configuration must be corrected before the match can complete — Atlar never silently books an unexplained difference.

Currency and exchange-rate handling

Three currencies matter for any match: the document currency (what the invoice or payment is denominated in), the bank account currency (what the transaction actually settled in), and the GL entity's base currency (the subsidiary's reporting currency). A match is cross-currency whenever these don't line up in a way that requires conversion, and Atlar's job is to decide whether an exchange rate is needed, what that rate is, and where to record it.

When an exchange rate is involved

ERP systems only support cross-currency settlement from an account denominated in the base currency. That constraint produces a fixed set of allowed combinations:

Document currency	Bank currency	Base currency	Outcome
EUR	EUR	EUR	Exact match; no FX rate
GBP	GBP	EUR	Exact match; no FX rate (same instructed currency settles in itself)
GBP	EUR	EUR	Cross-currency; matched within tolerance and the document is patched with an FX rate
EUR	GBP	EUR	Not allowed (foreign account cannot settle the base currency)
USD	GBP	EUR	Not allowed (two foreign currencies)
A leg that settles in its own currency carries no exchange rate even when the subsidiary's base currency differs — the ERP handles that translation itself.

Two further limits apply to transfers between own accounts:

An intra-company cross-currency transfer (both legs on the same legal entity) requires exactly one leg in the entity's base currency, so the clearing account can settle.
An intercompany transfer is rejected when the two subsidiaries have distinct base currencies that both differ from the settlement currency. A single bank rate cannot reconcile that shape.

How the rate is determined

When a match is materialized, document amounts must be expressed in the bank currency to compute the residual. Atlar selects the rate through a fixed precedence:

1. Transaction-provided rate. If the bank transaction carries a usable currencyExchange (both currencies set and different), the document's instructed amount is converted using that rate. This is the primary path and the rate the bank reported is the one used. When that quote is coarsely rounded, it may be refined — see Rate sharpening below.

2. Base-amount agreement (fallback). If no transaction rate is available and the match is not MANUAL, Atlar checks whether the sum of the documents' baseAmount exactly equals the bank transaction total. If it does, documents are valued by their baseAmount — the ERP and bank already agree on the base-currency figure, so no rate needs to be derived. Each outgoing document still carries its own currencyExchange as ERP metadata.

3. Totals-derived rate (MANUAL only). For manually created matches, when no transaction rate is present Atlar may derive a rate from the document and transaction totals. If none of these apply — for example a baseAmount is present but does not exactly match the transaction total — the fee-versus-FX difference is ambiguous and the match is rejected with AmountMismatch. The same rejection occurs when documents lack a usable baseAmount in the bank currency and no transaction rate exists.

No-document transfers

For transfers between the customer's own accounts with no ERP document, the rate is sourced from the bank movements themselves, in this order:

Bank-provided rate on a leg — if either the sending or receiving leg carries an explicit rate, that rate is used and recorded on that converting leg.
Derived from the two amounts (MANUAL matches only) — if neither leg booked a converting rate, Atlar may imply the rate from the fee-adjusted sending and receiving amounts. Rule-based matches cannot invent a rate this way; they are rejected until a bank rate is present or the match is created manually.
Rounding sharpened — when the residual is purely bank-rate rounding, the rate is sharpened to the precision implied by the amounts rather than booking a spurious over-payment (see below).

Rate sharpening (rounded bank quotes)

Banks usually quote an exchange rate at coarse precision (often two decimals, e.g. 1.15). Re-applying that rounded rate in the reverse direction can lose a minor unit — 10,000.00 GBP × 1.15 = 11,500.00 EUR, but the movement net of charges was actually 11,511.50 EUR, implying 1.15115. Left alone, that gap looks like a residual (a spurious over-payment or fee).

Rate sharpening replaces the rounded quote with the precise rate implied by the amounts, so the match balances exactly and no bogus residual document is booked. It only ever refines the bank's own quote — it never fabricates a rate to absorb a genuine difference.

Technical detail: the guards that must all pass

- A bank rate must already exist — sharpening never runs when there's no bank rate to refine.

The quote must be rounded — integer rates (zero fractional digits) are skipped.
The gap must be within the rounding budget — anything larger is a real residual, handled normally.
The precise rate must round back to the quote — proving it's the same rate at higher precision, not a different one.
The residual must go to exactly zero once re-valued with the sharpened rate.

When all guards pass, the sharpened rate supersedes the bank quote and is stamped on the resulting document or transfer leg. For no-document transfers, the rate is derived from the converting leg's booked and instructed amounts — booked minus fee on a sending leg, booked plus fee on a receiving leg — so the clearing account nets to zero in the base currency.

Where the rate is recorded

The exchange rate is attached to the converting side of the match — the document or journal leg that is not already in the settlement currency:

Document-backed matches — the created payment (or patched instruction document) carries the FX rate.
Intra-/intercompany transfers — only the leg whose bank account differs from the settlement currency carries a currencyExchange; the leg already in the settlement currency carries none.

Scenarios

The scenarios below show how Atlar materializes a confirmed reconciliation match into accounting documents, and how those land in NetSuite. A row is listed only when both sides work: Atlar can build the outgoing documents, and NetSuite can post or patch them. Unless noted, the GL entity's base currency is EUR and GBP is the foreign currency (cross-currency settlement is only possible from a base-currency account); amounts are signed by direction (+ inbound, − outbound). In the Documents column, a SOURCE document (e.g. an invoice) causes a new payment to be created and applied, an INSTRUCTION document (e.g. an existing payment or journal entry) is patched with the transaction's date and any FX rate, and None means a creation template defines the entry. The Residual column explains any gap between the bank movement and the documents, resolved in order: included charges and ALWAYS-template lines, then residual-driven creation templates, then a tolerance fallback (bank fee, over-payment, or absorbed FX difference).

#	Scenario	Documents	Transaction(s)	Residual	Result in Atlar	Result in NetSuite
	Exact matches (no residual)
1	Interest credit matched against no document	None	Inbound EUR +25.00	None — creation template defines the entry	Journal entry created: debit bank account, credit interest income account.	Journal entry created: debit bank account, credit interest income account.
2	Outbound bank service charge matched against no document	None	Outbound EUR −5.00	None — creation template defines the entry	Journal entry created: credit bank account, debit bank fee account.	Journal entry created: credit bank account, debit bank fee account.
3	Customer invoice matched exactly	Customer invoice (SOURCE) EUR +100.00	Inbound EUR +100.00	None (exact match)	Payment created, applied to invoice.	Customer payment created, applied to invoice.
4	Customer invoice in GBP matched exactly against GBP bank transaction	Customer invoice (SOURCE) GBP +100.00 (EUR 113.00 base)	Inbound GBP +100.00	None (exact match — same instructed currency, no FX needed)	Payment created in GBP, applied to invoice.	Customer payment created in GBP, applied to invoice.
5	Vendor invoice matched exactly	Vendor invoice (SOURCE) EUR −75.00	Outbound EUR −75.00	None (exact match)	Payment created, applied to invoice.	Bill payment created, applied to bill.
6	Customer payment matched exactly	Customer payment (INSTRUCTION) EUR +100.00	Inbound EUR +100.00	None (exact match)	Existing payment patched with transaction date.	Customer payment patched with transaction date.
7	Undeposited customer payment matched against bank deposit	Customer payment (SOURCE) EUR +100.00 posted against Undeposited Funds transit account	Inbound EUR +100.00	None (exact match)	Payment created, applied to source payment document.	Deposit created, moving funds from Undeposited Funds to bank account.
8	Vendor payment matched exactly	Vendor payment (INSTRUCTION) EUR −75.00	Outbound EUR −75.00	None (exact match)	Existing payment patched with transaction date.	Bill payment patched with transaction date.
9	Journal entry matched against transaction	Journal entry (INSTRUCTION) EUR +25.00 with bank line	Inbound EUR +25.00	None (exact match)	Existing journal entry patched with transaction date.	Journal entry patched with transaction date.
10	Customer refund matched against transaction	Customer payment (INSTRUCTION) EUR −25.00	Outbound EUR −25.00	None (exact match)	Existing payment patched with transaction date.	Customer refund patched with transaction date.
	Same-currency residuals
11	Customer invoice greater than transaction — bank fee on charges field	Customer invoice (SOURCE) EUR +100.00	Inbound EUR +98.00 (with EUR 2.00 included charge)	Bank fee (charges field) explains EUR 2.00 residual	Payment created for full EUR 100.00 applied to invoice + journal entry for EUR 2.00 bank fee.	Customer payment created, applied to invoice with full EUR 100.00. Journal entry created debiting Reconciliation Configuration's bank fee account.
12	Transaction greater than vendor invoice — bank fee on charges field	Vendor invoice (SOURCE) EUR −75.00	Outbound EUR −75.15 (with EUR 0.15 included charge)	Bank fee (charges field) explains EUR 0.15 residual	Payment created for EUR −75.00 applied to invoice + journal entry for EUR 0.15 bank fee.	Bill payment created, applied to bill with full EUR 75.00. Journal entry created debiting Reconciliation Configuration's bank fee account.
13	Bank fee already itemized on the matched journal — no second fee booked	Journal entry (SOURCE) EUR +98.00 that already includes a EUR 2.00 fee line	Inbound EUR +98.00 (with EUR 2.00 included charge)	None — documents already total the settled amount, so the charge is not folded in again	Journal entry patched with transaction date. No `BANK_FEE` journal.	Journal entry patched with transaction date.
14	Transaction greater than vendor invoice — creation template explains residual (journal entry)	Vendor invoice (SOURCE) EUR −100.00	Outbound EUR −110.00	EUR 10.00 overpayment — creation template (journal entry) absorbs residual	Payment created for EUR −100.00 applied to invoice + journal entry created for EUR 10.00.	Bill payment created, applied to bill with EUR 100.00. Journal entry created for EUR 10.00.
15	Transaction greater than customer invoice — creation template explains residual (overpayment payment)	Customer invoice (SOURCE) EUR +100.00	Inbound EUR +110.00	EUR 10.00 overpayment — creation template (payment) absorbs residual	Payment created for EUR 100.00 applied to invoice + unapplied payment for EUR 10.00.	Customer payment created, applied to invoice with EUR 100.00. Customer deposit of EUR 10.00 created.
16	Transaction greater than customer invoice — residual within overpayment tolerance	Customer invoice (SOURCE) EUR +100.00	Inbound EUR +110.00	EUR 10.00 overpayment within tolerance	Payment created for EUR 100.00 applied to invoice + overpayment payment for EUR 10.00.	Customer payment created, applied to invoice with EUR 100.00. Customer deposit of EUR 10.00 created.
17	Customer invoice greater than transaction — residual within bank fee tolerance	Customer invoice (SOURCE) EUR +100.00	Inbound EUR +99.00	EUR 1.00 underpayment within bank fee tolerance — treated as fee	Payment created for full EUR 100.00 applied to invoice + journal entry for EUR 1.00 bank fee.	Customer payment created, applied to invoice with full EUR 100.00. Journal entry created debiting Reconciliation Configuration's bank fee account.
18	Transaction greater than vendor invoice — residual within overpayment tolerance	Vendor invoice (SOURCE) EUR −100.00	Outbound EUR −110.00	EUR 10.00 vendor overpayment within tolerance	Payment created for EUR −100.00 applied to invoice + unapplied vendor payment for EUR −10.00.	Bill payment created, applied to bill with EUR 100.00. Vendor prepayment created for EUR 10.00.
	Multi-document and multi-transaction cardinality
19	One transaction pays multiple customer invoices	Three customer invoices (SOURCE) EUR +100.00 / +120.00 / +80.00	Inbound EUR +300.00	None (exact match across all invoices)	One payment per invoice created (3 payments), each applied to its invoice.	One customer payment created per invoice.
20	One transaction pays multiple vendor invoices	Three vendor invoices (SOURCE) EUR −100.00 / −120.00 / −80.00	Outbound EUR −300.00	None (exact match across all invoices)	One payment per invoice created (3 payments), each applied to its invoice.	One bill payment created per bill.
21	Two transactions settle one customer invoice	Customer invoice (SOURCE) EUR +250.00	Inbound EUR +150.00 + Inbound EUR +100.00	None (transactions sum to invoice amount)	One payment per transaction created (2 payments), both applied to the same invoice.	One customer payment created per transaction, applied to the same invoice.
22	Two transactions settle one vendor invoice	Vendor invoice (SOURCE) EUR −250.00	Outbound EUR −150.00 + Outbound EUR −100.00	None (transactions sum to invoice amount)	One payment per transaction created (2 payments), both applied to the same invoice.	One bill payment created per transaction, applied to the same bill.
23	One payment instruction settled by multiple bank movements	Vendor payment (INSTRUCTION) EUR −300.00	Multiple outbound EUR movements summing to EUR −300.00	None (transactions collectively settle instruction)	Existing payment patched; date is left unchanged because several bank dates are present.	Bill payment keeps its own date.
24	Batch payment run debits bank once, covers multiple payment instructions	Three vendor payment instructions (INSTRUCTION) EUR −100.00 / −120.00 / −80.00	Single outbound EUR −300.00	None	Each instruction patched with transaction date (3 patches).	Bill payments patched with transaction date.
25	One bank movement covers an existing payment instruction and a separate unpaid invoice	Vendor payment (INSTRUCTION) EUR −50.00 + Vendor invoice (SOURCE) EUR −50.00	Single outbound EUR −100.00	None	Existing payment instruction patched with transaction date + new payment created applied to the unpaid invoice.	Bill payment patched with transaction date + bill payment created, applied to bill.
	Cross-currency (explicit exchange rate)
26	Customer invoice differs from transaction — explicit exchange rate explains residual	Customer invoice (SOURCE) GBP +100.00	Inbound EUR +115.00 with explicit GBP/EUR 1.15 rate	FX difference explained by exchange rate	Payment created in GBP 100.00 with FX rate attached, applied to invoice.	Customer payment created with FX rate reported on transaction, applied to invoice.
27	Vendor invoice differs from transaction — explicit exchange rate explains residual	Vendor invoice (SOURCE) GBP −100.00	Outbound EUR −115.00 with explicit GBP/EUR 1.15 rate	FX difference explained by exchange rate	Payment created in GBP −100.00 with FX rate attached, applied to invoice.	Bill payment created with FX rate reported on transaction, applied to bill.
28	Customer payment differs from transaction — explicit exchange rate explains residual	Customer payment (INSTRUCTION) GBP +100.00	Inbound EUR +115.00 with explicit GBP/EUR 1.15 rate	FX difference explained by exchange rate	Existing payment patched with transaction date and FX rate.	Customer payment patched with transaction date and FX rate.
29	Vendor payment differs from transaction — explicit exchange rate explains residual	Vendor payment (INSTRUCTION) GBP −100.00	Outbound EUR −115.00 with explicit GBP/EUR 1.15 rate	FX difference explained by exchange rate	Existing payment patched with transaction date and FX rate.	Bill payment patched with transaction date and FX rate.
30	Transaction greater than vendor invoice — residual is bank-rate rounding, rate sharpened	Vendor invoice (SOURCE) GBP −10,000.00	Outbound EUR −11511.5 with GBP/EUR 1.15 rate	Residual is bank-rate rounding — rate sharpened to 1.15115, no overpayment booked	Payment created in GBP −10,000.00 with sharpened FX rate.	Bill payment created with a deduced rate; the rate reported by the bank is assumed to be rounded.
	Intracompany transfers
31	Intracompany transfer, same currency, no documents	None	Outbound EUR −100.00 (sending) + Inbound EUR +100.00 (receiving)	None	Two journal entries created: one per leg, each with bank + clearing lines.	Two journal entries created, balanced against the specified clearing account.
32	Intracompany cross-currency transfer, no documents — bank rate on a converting leg	None	Outbound EUR −115.00 (sending) + Inbound GBP +100.00 (receiving), bank rate on one leg	None — rate taken from the converting leg	Two journal entries created; FX rate attached to the foreign (non-base) leg.	Two journal entries created, balanced against the specified clearing account. Reported FX rate put on the converting leg.
33	Intracompany cross-currency transfer, no documents — no bank rate (`MANUAL` only)	None	Outbound EUR −115.00 + Inbound GBP +100.00 (amounts imply rate)	None — rate derived from the two amounts	Two journal entries created with derived FX rate on the receiving (foreign) leg.	Two journal entries created, each balancing a clearing account. Derived FX rate put on receiving leg.
34	Intracompany transfer matched with existing journal entry	Intracompany journal entry (INSTRUCTION) EUR	Outbound EUR −100.00 + Inbound EUR +100.00	None (exact match)	Existing journal entry patched with sending transaction date.	Journal entry patched with sending transaction date.
35	Intracompany cross-currency transfer matched with existing TRANSFER document	Transfer document (INSTRUCTION) GBP	Outbound GBP −100.00 (sending, EUR base) + Inbound EUR +115.00 (receiving)	None — rate taken from converting (sending) leg	Existing transfer document patched with FX rate.	⚠️ Not supported. NetSuite does not allow API operations on transfers; this is a no-op.
36	Intracompany cross-currency transfer, no documents — foreign account sends to base account	None	Outbound GBP −100.00 (foreign account) + Inbound EUR +115.00 (base account)	None — rate taken from sending leg	Two journal entries created: sending leg in GBP with FX rate, receiving leg in EUR.	Two journal entries created, each balancing a clearing account. Reported FX rate put on sending leg.
37	Intracompany transfer, no documents, creation template adds extra line (e.g. bank fee)	None	Outbound EUR −100.00 (sending) + Inbound EUR +99.00 (receiving)	Bank fee via `ALWAYS` template additional line on the sending leg	Two journal entries created: additional line on sending leg.	Two journal entries created, each balancing a clearing account. Sending leg with an additional fee line.
	One-sided intercompany
38	Book one side of an intercompany transfer, no ERP document	None — `ALWAYS` journal template against IC AR/AP, counterparty = the other subsidiary	Inbound EUR +100.00 on entity A (entity B's bank movement is not in the match)	None — creation template defines the entry	One journal entry created on entity A: debit bank, credit IC receivable from entity B.	Journal entry created, with NetSuite `toSubsidiary` / eliminate routing from the GL-entity counterparty. This is a normal journal, not an Advanced Intercompany Journal.
39	Confirm one leg of an existing advanced intercompany journal	Advanced intercompany journal (INSTRUCTION) on entity A only	Inbound or outbound EUR on entity A	None (exact match)	Existing journal patched with transaction date and `ADVANCED_INTERCOMPANY` subtype.	Advanced Intercompany Journal patched on the header. A single-leg patch is enough when the sibling subsidiary is not linked in Atlar.
	Two-sided intercompany transfers
40	Intercompany transfer, same currency, no documents	None	Outbound EUR −100.00 (entity A) + Inbound EUR +100.00 (entity B)	None — auto-balanced at ERP	Two journal entries created, one per entity; bank lines auto-balanced against IC AR/AP at ERP.	Advanced Intercompany Journal created, auto-balanced by NetSuite.
41	Intercompany cross-currency transfer, no documents — bank rate or `MANUAL` derived rate	None	Outbound EUR −115.00 (entity A) + Inbound GBP +100.00 (entity B)	None — FX rate from the converting leg, or derived on a manual match	Two journal entries created with FX rate on the converting leg.	Advanced Intercompany Journal created with FX rate on the converting subsidiary's line, auto-balanced by NetSuite.
42	Intercompany transfer, creation-template fee line on sending side, no bank rate	None	Outbound EUR −100.00 (entity A) + Inbound EUR +99.00 (entity B)	EUR 1.00 fee added via creation template	Two journal entries created with an explicit fee line on the sending side.	Advanced Intercompany Journal created with fee line belonging to subsidiary A, auto-balanced by NetSuite.
43	Intercompany transfer, creation-template fee line on receiving side, no bank rate	None	Outbound EUR −100.00 (entity A) + Inbound EUR +99.00 (entity B)	EUR 1.00 fee added via creation template	Two journal entries created with an explicit fee line on the receiving side.	Advanced Intercompany Journal created with fee line belonging to subsidiary B, auto-balanced by NetSuite.
44	Intercompany transfer matched with IC journal, both subs EUR, both accounts EUR	Intercompany journal entry pair (INSTRUCTION) EUR	Outbound EUR + Inbound EUR	None (exact match)	Both journal entries patched with transaction date.	Advanced Intercompany Journal patched with sending transaction date.
45	Intercompany transfer matched with IC journal, both subs EUR, receiver account GBP	Intercompany journal entry pair (INSTRUCTION)	Outbound EUR + Inbound GBP	FX rate attached on the converting leg	Both journal entries patched; FX rate applied to the converting leg.	Advanced Intercompany Journal patched with FX rate on the converting subsidiary's line.
46	Intercompany transfer matched with IC journal, both subs EUR, both accounts GBP	Intercompany journal entry pair (INSTRUCTION) GBP	Outbound GBP + Inbound GBP	None (same currency across accounts, no FX attached)	Both journal entries patched with transaction date.	Advanced Intercompany Journal patched with sending transaction date.
47	Intercompany transfer matched with IC journal, receiver sub GBP, both accounts GBP	Intercompany journal entry pair (INSTRUCTION) GBP	Outbound GBP + Inbound GBP	None — GBP account settles in GBP, no FX attached	Both journal entries patched with transaction date.	Advanced Intercompany Journal patched with sending transaction date.
48	Intercompany transfer no documents, receiver sub GBP, both accounts GBP	None	Outbound GBP + Inbound GBP	None — GBP account settles in GBP, no FX rate attached	Two journal entries created; no FX rate on the EUR-base/GBP-account leg.	Advanced Intercompany Journal created, without any reported FX rate.
	Document-only netting
49	Reversal netted against the original instruction, no bank transaction	Two INSTRUCTION documents that sum to zero (e.g. a payment and its reversal)	None	None — documents must net to exactly zero. Creation templates are not allowed.	Each document patched with the match ID. No journal is created.	Each instruction patched with the match ID. Manual matches only.

Not supported

These shapes are rejected, or they materialize in Atlar but are not pushed to NetSuite:

Existing NetSuite TRANSFER records. Atlar can emit an update; but NetSuite does not allow API operations on transfers, so the patch is a no-op.
Many-to-many cross-currency matches (several transactions and several documents in different currencies).
Intra-company cross-currency transfers with no base-currency leg.
Intercompany transfers whose two subsidiaries have distinct base currencies that both differ from the settlement currency.
Automatic (non-manual) no-document transfers that need a derived FX rate because neither leg booked a converting rate.