REDA Financials Monsoon 2026 · v1.610 2 Aug 2026

REDA Financials AI — Monsoon 2026 (v1.610)

This release adds electronic invoicing: REDA Financials can now transmit a sales invoice to a country's tax authority as part of posting, and record the authority's answer against the invoice. It also rebuilds the packaged permission sets so they can be assigned to users on a Salesforce Platform licence, corrects the withholding-tax seed packs for seventeen countries, and fixes a posting failure that occurred when one of your own dimension fields was a formula.

Getting this version

Upgrade the REDA Financials package in your org the same way you install any managed package. To confirm you have it, open Setup → Installed Packages and check that the Version Number column next to REDA Financials reads 1.610 or higher. Everything described below refers to that version; if the column still shows 1.6 or lower, the upgrade has not completed and none of the steps here will find the components they refer to.

What the upgrade does not do for you

A Salesforce managed-package upgrade is deliberately conservative: it will not overwrite configuration you have changed. That protects your org, but it means three things are left for an administrator to do by hand in every org that upgrades. Miss any one of them and the feature is either invisible or broken.

Every new field in this release

These are the fields the upgrade installs. Each one needs placing on the layouts your users actually open, and — if you do not use the packaged permission sets — granting field-level security.

Two new objects also arrive with their tabs — E-Invoice Setup (the per-entity configuration) and E-Invoice Trail (the audit record). If you use your own permission sets, grant object permissions and tab visibility for both.

What an administrator must do, per org

1. Place the fields on your layouts. Go to Setup → Object Manager → Sales Invoice → Page Layouts, open each layout your users actually use, and drag E-Invoice Status, E-Invoice UUID and Skip E-Invoicing into an E-Invoicing section — create the section if your layout has none — then Save. Repeat on E-Invoice Trail for Provider Document ID. Do this for every layout and every record type in use: a field placed on one layout is still invisible on all the others.
2. 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 each of your own profiles or permission sets. Leave Read-Only ticked for E-Invoice Status, E-Invoice UUID and Provider Document ID. Clear it only on Skip E-Invoicing, and only for the people who should be allowed to opt an invoice out of filing.
3. Grant object access and tab visibility for E-Invoice Setup and E-Invoice Trail to your own permission sets, if you are not using ours.
4. Add the Ready to Send value to the E-Invoice Trail Status picklist. Every org upgrading into v1.610 has to do this — see the next section for the exact steps and why it matters most.
5. Add Skip E-Invoicing to the Sales Invoice Interface field set. Sales Invoice uses a custom entry form, so a field on the page layout is displayed but cannot be filled in. Go to Setup → Object Manager → Sales Invoice → Field Sets → Interface and add the field there as well. It ships available but not selected, because most orgs never file electronically.
6. Decide who may release held documents, if you file manually. All five packaged permission sets grant read only on E-Invoice Trail — deliberately, because it is audit evidence the system writes. Releasing a held document and retrying an errored one both mean editing the record, so out of the box only a System Administrator can do either. To delegate it: Setup → Permission Sets → New → Object Settings → E-Invoice Trails → tick Edit, then assign it to the people who own that queue.

The Ready to Send value — the step that breaks the feature

1. Open Setup → Object Manager → E-Invoice Trail → Fields & Relationships → Status.
2. Under the picklist values, choose New, type Ready to Send — with exactly that spelling and capitalisation — and Save. The app writes a literal string, so a near-miss such as "Ready To Send" keeps failing while looking correct to the eye.
3. Choose Reorder and move the new value directly below Draft, so the list reads in the order the process actually follows.
4. Confirm the field now offers all eight values: Draft, Ready to Send, Queued, Submitted, Accepted, Rejected, Error, Cancelled. If it lists only seven, this step has not been done and automatic submission will fail.

What's new

Send invoices electronically to a tax authority

Countries that mandate electronic invoicing require each sales invoice to be transmitted to the tax authority and returned with an official fiscal identifier before it is legally valid. REDA Financials now does this as part of posting, so nobody has to re-key invoices into a government portal.

You configure E-Invoice Setup once per entity: which country, which document types are in scope, and whether submission happens automatically on posting or waits for a person to release it. When an invoice is posted, an E-Invoice Trail record is created for it — one Trail per invoice, holding the entire conversation with the authority: what was sent, what came back, the fiscal identifier, and every retry. The invoice itself gains an E-Invoice Status and an E-Invoice UUID, so a user can see where it stands without leaving the invoice.

A Trail moves through a defined sequence: Draft (created, awaiting release) → Ready to Send → Queued → Submitted → Accepted or Rejected, with Error for anything that could not be delivered and Cancelled for a withdrawn document. Because many authorities answer asynchronously — minutes or hours later, not in the same request — a scheduled poll advances submitted documents to their final state.

Two things are handled explicitly. Trail creation runs after the invoice is committed, so a problem reaching the authority can never roll back or block the posting itself. And a Skip E-Invoicing checkbox on the Sales Invoice excludes that one invoice entirely.

Connecting to a specific country's authority requires an extension package; the core app ships the framework and the audit trail. Full guides: E-invoicing overview, E-Invoice Setup, E-Invoice Trail, E-invoicing a sales invoice and E-invoicing extensions.

E-Invoice Status Poll — a new Operations card

Tax authorities answer on their own schedule. The E-Invoice Status Poll asks the authority, once a day at a time you choose, what has happened to every invoice still sitting at Submitted, and moves each one to Accepted or Rejected. It appears as the twelfth card on Admin Console → Operations, alongside the existing scheduled jobs, with the same Schedule / Reschedule / Unschedule / Run Now controls and a live count of how many documents are waiting and how many are in error.

Run Now polls immediately without waiting for the next run. It makes one call per submitted document, so treat it as a deliberate action rather than a refresh button. Orgs that do not file electronically see a short "no active setup exists yet" note on the card and can ignore it. Full guides: E-Invoice Status Poll and the Operations tab.

What's fixed

Permission sets rebuilt so Platform users can be assigned them

The five packaged permission sets were tied to a Salesforce user licence. Any org whose accounting users are on a Salesforce Platform licence — which is most of them — simply could not assign them, and the error message did not explain why. A permission set's licence cannot be changed after it is created, so the only fix was to ship replacements.

There are now five new permission sets, identical in content and with no licence restriction: Accounting Admin, Accounting Controller, Accounts Payable, Accounts Receivable and Read Only, each named with a _v2 suffix.

Full guides: Permission sets, Licence assignment, Post-installation setup, Go-live checklist and Segregation of duties.

Withholding-tax seed packs corrected for 17 countries

The country tax packs used by the seeding wizard carried withholding-tax rates whose "applies to" scope did not match the values the field accepts. Those rates were silently skipped, so a seeded country came out missing withholding rules it should have had.

Seventeen packs were corrected: Argentina, China, Colombia, Ecuador, France, Ghana, Hong Kong, Indonesia, Kenya, Pakistan, Philippines, Sri Lanka, Tanzania, Uganda, Uruguay, Venezuela and Vietnam. Where a single rule mixed scopes that the model keeps apart — resident versus non-resident, company versus individual — the rule was split in two rather than widened, so each rate now states exactly who it applies to. Five Latin American VAT-retention rates were additionally re-expressed as a percentage of the net amount, which is how they are actually assessed.

Full guides: Tax seeding wizard, Tax rules and Entity tax registration.

Custom dimension fields that are formulas no longer break posting

REDA copies your own dimension fields from a source document onto the accounting entries it creates, so your reporting dimensions follow the money. If one of those fields was a formula or a roll-up on the destination object, the copy tried to write a value into a field that cannot be written, and the whole operation failed — most visibly when voiding a cash receipt.

Copying now checks whether the destination field can actually be written and skips it if not. Formula and roll-up fields keep computing their own values, exactly as intended. Nothing to configure: existing setups keep working, including field sets that mix writable and calculated fields. Full guides: Posting dimensions, Field-set extensibility and Voiding a cash receipt.

What's improved

Bulk status updates now respect sharing and field permissions

Anyone updating records they can genuinely edit sees no difference. A user reaching beyond their access now gets a clear per-record failure in the same results panel that already reports partial success — the rest of the batch still processes. If someone reports rows failing that used to succeed, the fix is to grant the access they should have had, not to work around it. Full guides: Bulk updates overview, Supported objects and Bulk status updates.

Activating a licence key now requires Customize Application

Entering a subscription licence key writes configuration metadata into the org, so it now requires the Customize Application permission — the permission that change genuinely needs. Previously any user who could reach the subscription screen could activate a key.

There is nothing to configure, provided whoever activates licences is a System Administrator, since they already hold that permission. If licence activation is delegated to a non-admin, grant that user Customize Application or have an administrator activate the key. Full guides: Subscription and licensing and Licence architecture.

How to check the upgrade actually worked

Frequently asked questions