REDA Financials Monsoon 2026 · v1.6 19 Jul 2026

REDA Financials AI — Monsoon 2026 (v1.6)

This is the first REDA Financials release with full notes — v1.5 shipped without them. It brings bank reconciliation for foreign-currency receipts and payments with a configurable rounding tolerance, a separate default bank account for expense payments, structured e-invoice XML in the OCR Inbox, a correction to the exchange rate used when a foreign-currency receipt is voided, and the restoration of every AI feature after the underlying model was retired.

Five new fields need placing and permissioning by hand. A managed-package upgrade does not add fields to a page layout you have customised, and it does not grant field-level security on your own permission sets or profiles. Work through What the upgrade does not do for you or your users will not see the new tolerance and bank-account fields at all.

Getting this version

Upgrade the REDA Financials package in your org. To confirm you have it, open Setup → Installed Packages and check the Version Number column next to REDA Financials reads 1.6 or higher.

What the upgrade does not do for you

Two things are always left to an administrator. First, the upgrade never places a new field on a layout you have customised — and nearly every live org has customised theirs. Second, field-level security ships only in the packaged REDA Financials permission sets; if your users are on your own permission sets or profiles, nothing has been granted to them and they will see nothing regardless of the layout.

Object	Field	Layout section	Access
Bank Account	Reconciliation Tolerance (Amount)	Bank Account layout → reconciliation / settings	Editable — Accounting Admin, Accounting Controller
Bank Account	Reconciliation Tolerance (%)	Bank Account layout → reconciliation / settings	Editable — Accounting Admin, Accounting Controller
Cash Disbursement	Bank Reconciliation Amount	Cash Disbursement layout	Read-only — system-populated
Cash Receipt	Bank Reconciliation Amount	Cash Receipt layout	Read-only — system-populated
Entity	Default Bank Account - Expenses	Entity layout → default bank accounts	Editable — Accounting Admin, Accounting Controller

Place each field on your layouts. Setup → Object Manager → the object in the table above → Page Layouts → open each layout your users actually use → drag the field into the named section → Save. Repeat for every layout and record type in use — a field placed on one layout is invisible on the others.
Grant field-level security if you do not use the packaged permission sets. Setup → Object Manager → the object → Fields & Relationships → the field → Set Field-Level Security → tick Visible for your own profiles or permission sets. Leave Read-Only ticked on the two Bank Reconciliation Amount fields; clear it on the tolerance and expenses-bank fields for Accounting Admin and Controller only.
Verify as an ordinary user, not as an administrator. Administrators see fields regardless of field-level security, so testing as yourself proves nothing. Open a Bank Account as an Accounting Controller and confirm the tolerance fields are visible and editable.

If you use the packaged REDA Financials permission sets, field-level security is handled for you: Accounting Admin and Controller can edit the tolerance and expenses-bank fields, and Accounts Payable, Accounts Receivable and Read Only get read access.

What's new

Bank reconciliation for foreign-currency receipts and payments

Bank matching can now reconcile receipts and payments whose currency differs from the bank account. It does this by comparing a bank-currency value — the receipt or payment Amount × Exchange Rate — against the bank statement line, rather than comparing two amounts in different currencies.

Because converted values rarely land on the exact cent a bank reports, a new Reconciliation Tolerance on the Bank Account absorbs small rounding differences. Within tolerance, the match is accepted automatically; beyond it, the difference is flagged for review rather than silently absorbed.

Set it per bank account, and it is off until you do. An Accounting Admin or Controller sets a non-zero Reconciliation Tolerance (Amount) — and optionally a percentage — on each Bank Account. Left blank or zero, the behaviour is exact-match, exactly as before. The tolerance applies only when the bank account is in the entity's functional currency.

Full guides: Automatic matching, Manual matching and Statement validation.

A separate default bank account for expenses, per entity

An entity can now nominate a Default Bank Account – Expenses, used for Cash Disbursements, the batch payment run, and auto-payments on Expense-type Purchase Invoices. Leave it blank and the entity's existing Default Bank Account is used, so nothing changes for orgs that do not need the split. Validation ensures the account you choose is active and belongs to that entity.

To use it, add the field to the Entity layout (see the manual steps above) and set it per entity where a distinct expense-payment account is wanted. Full guides: Entity fields and Entity default GL accounts.

An e-invoicing extension framework, for partners

A provider-neutral global API so partners can build e-invoicing provider extensions — outbound submission, inbound queue drain, artefact retrieval and self-service provisioning — on top of REDA. This is an extensibility surface for developers, not an end-user screen, and there is no end-user configuration. It is the foundation the full e-invoicing feature in v1.610 was built on.

What's improved

Voiding a foreign-currency cash receipt now uses the original exchange rate

Voiding a foreign-currency cash receipt now reverses at the original exchange rate, so the void nets the original exactly in the entity's functional currency. Previously the reversal used the rate at the void date, which introduced a spurious FX gain or loss that had to be explained away at period close.

Worked example. A receipt of USD 10,000 is recorded at a rate of 1.20, posting 12,000 in the entity's functional currency. It is voided a fortnight later, when the rate has moved to 1.25. Previously the reversal posted 12,500, leaving a 500 FX loss that no real transaction caused. It now reverses at 1.20 for 12,000 and nets to zero. A void is a correction, not a new settlement.

Nothing to configure — this is automatic. Full guide: Voiding a cash receipt.

The OCR Inbox reads structured e-invoice XML

The OCR Inbox — the intake hub for vendor invoices — now reads all attachments on an intake record rather than just the first. When a structured e-invoice XML is present, its data is treated as authoritative, because reading structured data is inherently more reliable than interpreting a PDF. The PDF remains as the human-readable copy.

With no XML present, or one that is unreadable or oversized, the Inbox falls back to exactly the previous PDF-based behaviour. This is automatic for existing OCR Inbox users, with nothing to configure. Full guides: The OCR Inbox, OCR overview and Creating an invoice from OCR.

Your own custom fields stay editable on posted and voided records

Record locking on posted and voided records now applies only to what genuinely affects accounting integrity. All packaged fields, standard fields and posting-mapping dimension fields stay locked, exactly as before. But any custom field you added yourself — as long as it is not a posting-mapping dimension — is now editable in every record state, so you can keep maintaining your own operational data on a document after it has been posted.

Accounting integrity is unchanged, and there is nothing to configure. Full guide: Entity policy settings.

What's fixed

AI features restored

The underlying AI model REDA Financials had been using was retired by its provider and began returning errors, which broke every AI-backed feature: OCR invoice scanning, bank-reconciliation automatic matching, and AI analysis. This version moves to the current model and all of those features work again.

There is no configuration change for subscribers — if you were affected, upgrading is the entire fix. Full guides: OCR overview and Automatic matching.

How to check the upgrade actually worked

Check	How	What you should see
The version installed	Setup → Installed Packages	REDA Financials at 1.6 or higher.
Tolerance fields are visible to real users	Open a Bank Account as an ordinary Accounting Controller, not as an admin	Both Reconciliation Tolerance fields present and editable.
The expenses bank account is available	Open an Entity record	Default Bank Account - Expenses on the layout, and selectable.
AI features are working again	Run an OCR scan on a sample vendor invoice	The scan completes and returns fields instead of erroring.

Frequently asked questions

No. Left blank or zero, matching requires an exact amount — the behaviour you had before this release. Set a tolerance only if you reconcile foreign-currency receipts or payments and want small rounding differences accepted automatically.

It is set per Bank Account, and it applies only when that bank account is in the entity's functional currency.

Yes. The failure was caused by the retired model, and this version moves to the current one. No configuration change is needed on your side.

Only if your page layouts are untouched package defaults and your users are on the packaged REDA Financials permission sets. If you have customised your layouts or use your own permission sets — most orgs do — you must place the fields and grant field-level security yourself. See the manual steps.