Payroll to finance
Loket to Oracle Fusion ERP integration: every Loket journal run as a journal import in the Oracle general ledger
With an integration between Loket and Oracle Fusion ERP, every Loket journal run automatically goes to the Oracle general ledger as a journal import, per payroll administration in the matching ledger and on the segments of the Oracle chart of accounts. Only once Oracle has imported the journal does KoppelHet mark the run as exported in Loket.
What the integration does
Organisations that process Dutch payroll in Loket and keep the general ledger in Oracle Fusion ERP, often within an international group, download the journal from Loket after every run and build an Oracle import file from it by hand. Payroll then only knows whether a run is already in Oracle by asking.
- Payroll runs payroll and journalises in Loket, as today.
- KoppelHet sees a journal run with results and fetches the lines per account, cost centre and cost unit.
- Account, cost centre and cost unit are translated to the Oracle segments through tables maintained by finance.
- KoppelHet loads the journal into Oracle and starts the journal import for the ledger of that payroll administration.
- If loading and importing succeeded, the run is marked as exported in Loket; otherwise as failed, with the reason.
What to watch for with Loket and Oracle Fusion ERP
- Loket itself only sends journal data to accounting packages a user is connected to through OAuth, such as Exact Online, Twinfield and AccountView. Oracle Fusion is not among them. KoppelHet therefore reads the results of every journal run through the Loket API and builds an Oracle import from them.
- Oracle determines the accounting period from the accounting date of each line. In Loket the journal configuration records how a pay period maps to a financial period, including a custom schedule if the financial year does not start in January. KoppelHet follows that setting when choosing the accounting date, so Loket and Oracle show the same period.
- If payroll recalculates a journal run after a shift in cost allocation, Loket only returns the difference, such as minus on the old and plus on the new cost unit. KoppelHet gives such a run its own group number, so Oracle makes a separate correction journal next to the original.
- Loading into the interface table and the journal import are two processes in Oracle that run in the background. Loket lets an external application set a run's status to exported or failed itself. KoppelHet only does so once the import process in Oracle has finished, with the error from the Oracle log if it goes wrong.
- Loket only starts a new journal run once the run of the previous payroll has succeeded. A run stuck in Oracle therefore blocks nothing in Loket, but a failed run in Loket does. KoppelHet reports both cases separately, so it is clear whether finance or payroll needs to act.
- Deleting a journal run in Loket changes nothing in other applications. If payroll undoes a run, KoppelHet tells finance which Oracle journal belongs to it. Oracle has its own reversal method per journal; that choice stays with finance.
- If several employers work in one Loket environment, each payroll administration has its own journal runs. In Oracle every journal belongs to one ledger. KoppelHet records the ledger per payroll administration, so the payroll costs of one employer never end up in the books of another.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Who posts the journal in Oracle?
Finance or the shared service centre. The integration imports the journal; posting remains a step in Oracle.
What if an account or cost centre does not exist in Oracle yet?
Then Oracle rejects the lines and the run shows as failed in Loket. Finance completes the lookup table or the segment, then the run goes again.
Can cost centres also go from Oracle to Loket?
That can be added later as an extension. Loket lets cost centres be created per journal profile through the API.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- Loket through the REST API with OAuth (authorization code flow): journal runs per payrollAdministrationId with journalRunStatus, GET .../journalruns/{journalrunId}/results with consolidate (BasedOnLedgerAccountConfiguration, Always or Never; no results for status 0 to 3), PATCH .../journalruns/{journalrunId} with markAsSuccessfullyExported or MarkAsProcessingFailed, and the journal configuration with methodForDeterminingAccountingPeriod and payrollPeriodFinancialPeriodMapping.
- Oracle Fusion through POST /fscmRestApi/resources/11.13.18.05/erpintegrations with OperationName importBulkData and a zip with the GL_INTERFACE file: STATUS NEW, LEDGER_NAME, ACCOUNTING_DATE, USER_JE_SOURCE_NAME, USER_JE_CATEGORY_NAME, CURRENCY_CODE, ACTUAL_FLAG A, SEGMENT1 onwards, ENTERED_DR, ENTERED_CR, GROUP_ID (positive integer; lines with the same GROUP_ID become one journal) and REFERENCE1, 4, 5 and 10 for batch, journal and line description. Errors are fixed through Correct Import Errors.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Loket | Field in Oracle Fusion ERP | Notes |
|---|---|---|
generalLedgerAccount | Natuurlijk-rekeningsegment | Lookup table from Loket account to Oracle segment |
costCenter | Kostenplaatssegment | |
costUnit | Ander segment, bijvoorbeeld project | Only if the chart of accounts has a segment for it |
debetAmount en creditAmount | ENTERED_DR en ENTERED_CR | With CURRENCY_CODE EUR |
Loonadministratie | LEDGER_NAME | Fixed mapping per payroll administration |
Periode van de journaalrun | ACCOUNTING_DATE | |
Journaalrun | GROUP_ID en REFERENCE4 (journaalnaam) |
Related
ADP Workforce Now → Loket
ADP Workforce Now to Loket integration: hires, pay, hours and bonuses from ADP to the Dutch payroll run
AlexisHR → Loket
AlexisHR to Loket integration: employees of the Dutch company from AlexisHR into payroll
BambooHR → Loket
BambooHR to Loket integration: HR changes from BambooHR for Dutch payroll
Bullhorn → Loket
Bullhorn to Loket integration: placement as a concept employee in the right payroll administration