Why Salesforce-Native Accounting
Most accounting software lives on its own island: its own logins, its own database, its own security model — and a bridge of integrations to everything else your company runs. REDA Financials makes a different choice. It is built natively on the Salesforce platform: every invoice, receipt, journal, and budget is a Salesforce record in your org. This article explains what that architecture buys you in practice — because it is the quiet reason behind most of what this knowledge base describes.
Access you'll need. Any user assigned a REDA Financials permission set — Accounts Payable v2, Accounts Receivable v2, Accounting Controller v2, Accounting Admin v2, or Read Only v2 — can open the app; what you can do depends on the set (AP the purchase side, AR the sales side, Controller and Admin the ledger and setup, Read Only view-only). Because it is native, the same Salesforce permissions, sharing, and field history described below govern that access.
Your customer is one record, not two
In REDA Financials, customers and vendors are Salesforce Accounts — the same records your sales and service teams already work every day, extended with accounting fields like payment terms, tax jurisdiction, and tax profile. There is no sync job between "CRM customer" and "accounting customer," because there is no second copy:
- Sales sees the outstanding balance on the account they're about to upsell.
- Finance sees the pipeline behind the invoice they're about to chase.
- An address changes once, everywhere, with field history recording who changed it.
That's the CRM dividend: a full customer-relationship platform — activities, opportunities, cases, campaigns — standing directly on your accounting master data, with nothing to integrate.
One security model, one audit story
Because accounting documents are platform records, they inherit the platform's controls instead of re-implementing them:
| Control | What you get |
|---|---|
| Permissions | Five shipped permission sets — Admin, Controller, AP, AR, Read Only — layered on Salesforce profiles, sharing rules, and field-level security. The controller who can post journals but only read invoices is configuration, not a feature request. |
| Record history | Created-by, modified-by, and per-field field history tracking on the documents you choose. |
| Access trail | The platform's login history and setup audit trail — who signed in from where, and who changed which configuration — cover your accounting automatically, because it lives where they watch. |
| Accounting's own guards | On top of the platform layer, REDA Financials adds the domain controls this KB documents: posting gates, immutable ledger entries, book-closure dates, approval gates, and a four-eyes rule on bank reconciliation. The two layers together are the compliance story. |
Every platform tool works on your books
| Platform capability | Applied to accounting |
|---|---|
| Reports & dashboards | Point the standard report builder at invoices, payments, or ledger entries — alongside the built-in financial statements. Your CFO's dashboard can mix pipeline and payables on one screen. |
| Flow automation | React to postings, chase stuck approvals, create draft documents from business events — clicks, not code, and every accounting guard still enforced. |
| Approval processes | Native sign-off routing on five gated documents, with permanent approval history. |
| AI | Embedded OCR and bank matching ship inside REDA Financials; the REDA AI platform adds configurable agents across the same org, under the same permissions. |
| APIs & extensibility | Standard REST/Bulk APIs, field sets for adding your fields to forms and PDFs, and an extension model — the platform's whole developer ecosystem applies. |
| Mobile & access | Accounting records, reports, and approvals are available wherever your Salesforce org is — including the Salesforce mobile app. |
One admin skill set
The person who administers your Salesforce org already knows how to manage users, permission sets, page layouts, reports, Flows, and approval processes. REDA Financials rides that knowledge: accounting-specific setup — entities, GL accounts, tax, periods — is documented in this KB, and everything around it is the platform your admin already runs. Teams evaluating accounting systems often underestimate this line item until they've lived the alternative.
Where this fits your evaluation
- Already on Salesforce? Your CRM data, security model, admin skills, and automation investments apply to your accounting from day one. Start with About REDA Financials and the setup roadmap.
- Multi-entity, multi-country? The accounting engine is global by design — entities, multi-currency, per-country tax, and international standards.
- Worried about lock-in to a niche vendor? Your data sits in your Salesforce org as standard-shaped records, queryable and exportable with standard APIs.
Where to go next
- About REDA Financials — the product tour.
- Key Concepts — the vocabulary the rest of this KB builds on.
- Compliance & Standards — the platform + accounting control stack, mapped to ISO, SOC, SOX, IFRS, and GAAP.
Frequently asked questions
REDA Financials runs on the Salesforce platform, so your users need platform access plus REDA Financials licensing — see License Assignment and Subscription Plans. Which Salesforce license types your users need depends on what else they do in the org; your administrator and REDA's team can map this for your case.
Only if you let them — and the shipped model doesn't. Accounting objects are governed by the REDA Financials permission sets; a user without one can't create or edit accounting documents at all. Sharing one database is not sharing one set of rights.
No. Your Salesforce org is your own tenant, and REDA Financials installs into it as a managed package. Your books live in your org, under your security configuration, visible only to your users.
Accounting records behave like all your other Salesforce data — same backups, same sandboxes, same release cadence. Test upgrades in a sandbox like any other org change; Installation & Upgrades covers the package side.
The platform hosts the records; the accounting engine is REDA Financials' own — double-entry posting, control accounts, multi-entity consolidation-ready structure, tax and withholding engines, period and book-closure discipline. Read How Posting Works and judge the engine on its mechanics.
REDA Financials requires a Salesforce org — that's what "native" means. If your CRM is elsewhere, the platform benefits described here become integration questions again, and the API section describes how systems reach your books.
Was this article helpful?