Automating financial exchange between Salesforce and Oracle Fusion
Two separate streams at one client: a Salesforce to Oracle Fusion Accounts Receivable integration automating financial data exchange, and a correction to the Net Present Value logic inside a custom payment-plan solution that property buyers’ instalment schedules depended on.
- Context
- A commercial real estate developer
- Role
- Senior IT Applications Engineer / Salesforce Developer
- Period
- 2024
- Systems
- Salesforce ⇄ Finance integration interface ⇄ Oracle Fusion AR
At a glance
Two outcomes, from two separate pieces of work: financial data moves between the CRM and the finance system of record automatically, and the numbers the business issues to buyers are correct.
- Oracle Fusion AR integration — designed and implemented the Salesforce integration with Oracle Fusion Accounts Receivable.
- Oracle Fusion AR integration — automated financial data exchange between Salesforce and the finance environment, removing a manual step.
- Oracle Fusion AR integration — established reliable enterprise data exchange between the two systems.
Jump to
Overview
What this was
One engagement, two separate technical streams. The first connected Salesforce to Oracle Fusion Accounts Receivable so financial data moved between them automatically instead of by hand. The second corrected the Net Present Value logic inside a custom payment-plan solution, restoring the accuracy of the instalment schedules it produced. They are presented together because they were the same engagement — not because one caused, contained, or depended on the other. They are different disciplines: one is integration design against an external contract, the other is financial business logic where being approximately right is the same as being wrong.
Business context
A real estate developer running property sales and customer operations on Salesforce, with Oracle Fusion as the finance system of record. Accounts receivable, instalment plans, and the discounting applied to them are governed by finance, not by the CRM — so the platform’s job is to produce something the finance system will accept, and to compute buyer-facing numbers correctly before it does.
Delivery timeline
- 01
Requirements
Established what finance needs from a Salesforce-originated transaction.
- 02
Interface design
Agreed the contract between Salesforce and Oracle Fusion AR.
- 03
Build
Implemented the integration and automated the financial data exchange.
- 04
Payment-plan defect
Separate stream — traced and corrected the NPV calculation logic.
- 05
Security model
Profiles, permission sets, roles, and sharing rules across the process.
Business problem
Two separate problems at the same client: financial data had to move between the CRM and the finance system of record reliably, and — independently — the payment schedules the business issued to buyers were being calculated on Net Present Value logic that was wrong.
Stream 1 — Two systems, one financial truth
Salesforce originates the commercial event; Oracle Fusion decides whether it is a valid financial one. Without an interface between them, that reconciliation is manual work.
Stream 1 — Manual financial data exchange does not scale
Re-keying financial data between a CRM and an ERP is slow, and every transcription is an opportunity for a number to change on the way.
Stream 2 — Incorrect NPV produced incorrect payment schedules
A custom payment-plan solution was calculating Net Present Value incorrectly. That is not a display bug — it changes the instalment amounts a buyer is asked to pay.
Both — A finance-facing process needs a real security model
Who can see and change financial records is a control question, not a convenience one, and it needed designing rather than inheriting.
Challenges
What made this harder than it looks
- 01
Stream 1 — the finance system defines the contract
Oracle Fusion AR rejects rather than negotiates. The integration has to produce exactly what the ledger expects, and the platform team does not get a vote on what that is.
- 02
Stream 2 — financial defects are silent to the person who caused them
An incorrect NPV does not raise an error. It produces a plausible number, on a real schedule, sent to a real buyer — which is why it survived until someone checked the arithmetic rather than the output.
- 03
Stream 2 — discounted cash flow has to be right, not approximately right
Net Present Value depends on the discount rate, the timing of each instalment, and the period convention. Getting any one of those wrong produces an answer that looks entirely reasonable.
- 04
Stream 2 — the fix landed on a live commercial process
Payment plans were already being issued. Correcting the calculation had to account for what had already gone out, not only for what came next.
Architecture
How the system fits together
The diagram below covers the Oracle Fusion AR integration only. Salesforce originates and holds the commercial transaction; a finance integration interface carries the financial data to Oracle Fusion Accounts Receivable. The payment-plan work was a separate stream and is deliberately not drawn here — there is no evidence it formed part of this integration, so showing it inside this flow would imply a connection that has not been established. The interface node is abstract on purpose; see the note below the diagram.
- Transaction to Apex integration layer: financial data
- Apex integration layer to Finance integration interface: exchange
- Finance integration interface to Oracle Fusion AR: post receivable
- Oracle Fusion AR to Finance integration interface: outcome
- Finance integration interface to Apex integration layer: reflect
End-to-end flow
- 01
The commercial transaction originates in Salesforce
The sale, the customer, and the agreed terms are captured against the record the business actually works from.
- 02
Financial data is shaped for the ledger
The transaction is composed into the form Oracle Fusion Accounts Receivable expects, rather than sent as a Salesforce record.
- 03
The interface carries it to Oracle Fusion
Financial data is exchanged with the finance system of record over a defined, secured interface rather than re-keyed by a person.
- 04
Oracle Fusion AR posts the receivable
The finance system applies its own validation and records the receivable against the customer.
- 05
Access is governed end to end
Profiles, permission sets, roles, and sharing rules determine who can see and change the records on the Salesforce side of the process.
Technologies
Stream 1 — Oracle Fusion AR integration
- Apex
- REST APIs
- Oracle Fusion
- Accounts Receivable
- Enterprise data exchange
Stream 2 — Payment plan / financial logic
- Apex
- Custom payment-plan solution
- Net Present Value calculation
Across both
- Lightning Web Components
- Salesforce Flow
- Profiles, permission sets, roles, sharing rules
Solution design
The choices that shaped everything else
Stream 1 — Salesforce produces what the ledger expects, not what it holds
Financial data is composed into the shape Oracle Fusion Accounts Receivable accepts rather than serialising a Salesforce record onto the wire. The finance system owns the contract; the platform’s job is to satisfy it without dragging the CRM schema across the boundary.
Stream 1 — The exchange is automated, so it is repeatable
Moving financial data through a defined interface instead of a person removes the transcription step entirely — which is where a number quietly changes between two systems.
Stream 2 — NPV is computed in one place, and it is testable
The discounted cash flow behind a payment plan is deterministic arithmetic. It belongs in code that can be checked against a worked example, not spread across the places that happen to need a figure.
Both — Access is designed, not inherited
Profiles, permission sets, roles, and sharing rules were designed for a process that touches financial records, rather than extended from whatever the org already had.
Technical decisions
What was decided, why, and what it cost
Every decision below is paired with its trade-off. A design choice without a stated cost usually means the cost was not examined.
Stream 2 — correct the NPV calculation rather than adjust the outputs
Rationale
The schedules were wrong because the discounted cash flow was wrong. Fixing the calculation makes every future plan correct by construction; correcting individual schedules would have left the defect in place and created permanent manual work behind it.
Trade-off
It required understanding the finance intent well enough to be certain the calculation was wrong rather than the expectation — slower than patching an output, and the right order.
Stream 1 — automate the financial exchange rather than run a manual export
Rationale
A defined interface between Salesforce and Oracle Fusion AR makes the exchange repeatable and auditable. An export-and-import cycle is a person with a spreadsheet, which does not scale and cannot be reviewed.
Trade-off
An interface has to be maintained and monitored, and it fails in ways a person would have noticed. Worth it for anything touching a ledger.
Stream 2 — treat the payment-plan defect as its own piece of work
Rationale
The instalment engine is a self-contained calculation problem. Handling it separately from the integration meant the fix could be reasoned about and validated on its own terms, against finance, rather than tangled into a delivery with an entirely different failure mode.
Trade-off
Two threads running at once rather than one. Correct: they share a client and a domain, not a codepath.
My responsibilities
What I personally owned
- Oracle Fusion AR integration — delivered the Salesforce integration with Oracle Fusion Accounts Receivable to automate financial processes.
- Oracle Fusion AR integration — enabled secure, reliable enterprise data exchange between Salesforce and the finance environment.
- Payment plan / financial logic — traced and corrected the Net Present Value calculation logic in a custom payment-plan solution.
- Payment plan / financial logic — restored accurate financial results and reliable payment schedules.
- Designed and enhanced Salesforce solutions against complex business and operational requirements.
- Designed and implemented the Salesforce security model using profiles, permission sets, roles, and sharing rules.
Implementation process
How it was actually built
- 01
Stream 1 — established what finance actually needs
The finance system defines the contract, so the first work was confirming its expectation rather than designing from the Salesforce side and hoping the ledger agreed.
- 02
Stream 2 — checked the arithmetic, not the output
The payment-plan defect produced plausible numbers. Finding it meant working through the discounted cash flow against a known-correct example rather than reviewing schedules for something that looked odd.
- 03
Stream 2 — corrected the calculation at the cause
Fixing the NPV logic itself made every subsequently generated plan correct, instead of leaving a defect in place behind a correction step.
- 04
Both — designed the access model alongside the build
Security for a finance-adjacent process was treated as part of the delivery rather than as a hardening pass afterwards.
Security considerations
What was protected, and how
The security model was designed for the process
Profiles, permission sets, roles, and sharing rules were implemented specifically around who should see and change financial records, rather than inherited from the wider org.
Financial data crosses one defined path
Data reaches the finance system through a single interface, so there is one place to authorise, monitor, and audit rather than several.
Credentials are held outside code
Authentication to the finance interface is configured through the platform credential store, so nothing sensitive is committed to version control.
Business value
Two outcomes, from two separate pieces of work: financial data moves between the CRM and the finance system of record automatically, and the numbers the business issues to buyers are correct.
- Oracle Fusion AR integration — designed and implemented the Salesforce integration with Oracle Fusion Accounts Receivable.
- Oracle Fusion AR integration — automated financial data exchange between Salesforce and the finance environment, removing a manual step.
- Oracle Fusion AR integration — established reliable enterprise data exchange between the two systems.
- Payment plan / financial logic — corrected the Net Present Value calculation logic in a custom payment-plan solution.
- Payment plan / financial logic — improved the accuracy of financial results and the payment schedules derived from them.
- Both streams — established a designed security model over the records the process touches.
Lessons learned
What I took from it
Financial logic fails plausibly, which is why it needs testing
An incorrect discount calculation does not throw. It returns a number that looks like an answer. Deterministic financial arithmetic has to be provable against a worked example, because nothing else will catch it.
Automating an exchange removes a whole class of error
Most of what goes wrong between a CRM and an ERP goes wrong in the human step between them. Removing that step is worth more than making it faster.
The domain expert is in finance, not in the platform team
Whether a figure is correct is an accounting question. The work was only safe because the people who could answer it were part of the loop.
Integration and business logic are different disciplines
This engagement needed both, in parallel and independently: a contract with an external system, and arithmetic that had to be exactly right. They fail differently, they are tested differently, and treating them as one piece of work would have served neither.
Future improvements
What I would do next
Listing the known gaps is part of the handover. A system described as finished usually means nobody looked hard enough.
Publish the payment-plan engine as its own case study
The instalment logic — NPV, interest, and discounting — is the strongest pure business-logic example in this history and currently sits inside a larger integration story. It would carry a case study of its own.
Improvement 1Regression tests around the financial calculations
A suite of worked examples asserting the discounted cash flow would make this class of defect impossible to reintroduce.
Improvement 2Monitoring on the financial exchange
Surfacing failed or delayed exchanges to a person, rather than waiting for finance to notice a gap, is the obvious next reliability step.
Improvement 3
Keep reading