Extension Architecture

Admin 6 min read Updated July 2026

Some capabilities are inherently local or provider-specific — government e-invoicing mandates, bank data feeds. REDA Financials handles them with an extension architecture: the core stays provider-agnostic, and pluggable extension packages supply the country- or provider-specific connections.

The model

The core ships the sockets: configuration objects that describe where a provider plugs in — an e-invoice setup per entity, a bank feed setup per bank account — plus the audit objects that record what flows through.
Extensions ship the plugs: a provider extension package implements the actual connection (a national e-invoicing clearinghouse, a bank aggregation service) and registers itself in that configuration.
Your documents never change: invoices, receipts and statements stay identical whichever provider is behind them. Swap providers and the accounting doesn’t notice.

Think wall socket, not rewiring. The core ships the socket and the wiring behind it; a provider extension is the plug. Changing electricity suppliers never meant rewiring the house — changing e-invoicing or feed providers shouldn't mean rewiring the books, and here it doesn't.

Who supplies what

The socket-and-plug division of labour is worth spelling out, because it decides who you call when something needs to change:

Piece	Supplied by	Examples
The sockets — configuration describing where a provider plugs in	The REDA Financials core	An e-invoice setup per entity; a bank feed setup per bank account
The audit objects — the record of what flows through	The core	The submission trail attached to each e-invoiced document
The plugs — the actual connection to a provider	An extension package	A national e-invoicing clearinghouse connection; a bank aggregation service
The choice of provider — which plug fills which socket	You, in configuration	Pointing an entity's e-invoice setup at the installed provider

What it means for each role

Role	What changes with an extension	What never changes
Administrator	Installs the provider's extension package and registers it in the relevant configuration — per entity or per bank account.	The Admin Console, the core setup, the upgrade calendar of the accounting core.
Accounting user	Nothing. Invoices, receipts and statements are created and posted exactly as before.	Every screen, every habit — the documents stay identical whichever provider is behind them.
Auditor / reviewer	Gains a per-document trail of what flowed through the extension point.	The core evidence chain: Audit Log, field history, immutable ledger.

The two extension points today

Extension point	What it enables	Details
E-Invoicing	Submitting invoices to government platforms where law requires it, with a full submission trail per document.	E-Invoice Extensions
Bank Feeds	Automatic bank statement delivery from aggregation providers, feeding importing bank statements without CSVs.	Bank Feed Extensions

Two sockets, today. E-invoicing and bank feeds are the extension points that exist now. Both follow the same pattern, so once you've configured one, the other holds no surprises — and future extension points will read the same way.

Why it’s built this way

Mandates and providers churn — countries phase e-invoicing in, banks change aggregators. Keeping those integrations in separate packages means your accounting core upgrades on its own calendar, extensions on theirs, and a regulation on the far side of the world never destabilizes your close. It also means configuration-driven extensibility everywhere: extensions can add their fields to documents and PDFs without code changes to the core.

A worked example — Meridian's two plugs

Meridian Properties Group's org shows both extension points in use, and the pattern holding either way:

Brazil needs government e-invoicing

Brazil runs an invoice clearance regime, so the administrator installs the provider's extension package and points the Brazilian entity's e-invoice setup at it. From then on, every posted invoice's submission — sent, accepted or rejected, with the authority's response — is recorded on the invoice's trail. The AR team's workflow didn't change by a single click.

The US bank offers a feed

The administrator installs a feed provider's extension and registers it on the operating bank account's feed setup. Statements now arrive by themselves as ordinary bank statements and lines — identical to the CSV imports the UK entity still does by hand, so reconciliation reads the same in both countries.

A provider changes — the books don't

If Brazil's provider is ever swapped, the new plug fills the same socket: documents, trails and accounting stay identical. That swap-without-rework is the whole argument for the architecture.

Common mistakes to avoid

Mistake	Why it hurts	Do this instead
Building a custom integration where an extension point exists	You re-implement the socket the core already ships — and own the maintenance forever	Use the extension point; ask REDA what provider packages exist for your countries and banks
Waiting for an extension before setting up the core	Nothing about core setup needs rework when an extension arrives — waiting just delays the books	Configure entities, banks and documents now; plug providers in when ready
Expecting users to learn new steps when an extension goes live	They shouldn't — extensions ride on posting and statement arrival, not on new habits	If a rollout plan includes retraining document entry, question the plan
Coupling your close calendar to an extension's upgrade	The core and extensions deliberately upgrade on separate calendars	Treat extension updates as their own small events, not close blockers
Assuming one provider covers every country or bank	Mandates and coverage are regional by nature	Check availability per country and per bank — the two detail articles say how

Plan by mandate, not by technology. The right trigger for an e-invoicing extension is a country's legal timetable; for a bank feed, the bank's provider coverage. Keep a simple list of your countries and banks against those two questions and the extension roadmap writes itself.

Where to go next

E-Invoice Extensions · Bank Feed Extensions — the two points in practice.
Extension Packages (Developer view) — for teams building one.

Frequently asked questions

No — that's the design's central promise. Documents stay identical whichever provider is behind them; extensions change what happens around posting and statement arrival, never the documents themselves.

The new extension registers in the same configuration socket, and your documents and audit trails carry on unchanged — the accounting doesn't notice the swap.

No — deliberately. The core upgrades on its own calendar and each extension on its own, so a provider or mandate change never destabilizes your close.

Yes — the configuration-driven design lets extensions add their fields to documents and PDF layouts without code changes to the core setup you already have.

Two points today — e-invoicing and bank feeds. Provider availability evolves by country and region; ask REDA about yours.

Was this article helpful?