What access will an ERP integration require, and could it change anything in the system? For Centinel, the architectural answer is specific: the connection reads journal entry data through published APIs and has no write endpoint in its integration path. That distinction matters to the teams responsible for SAP S/4HANA or Oracle ERP Cloud, because read permissions alone do not fully describe the technical boundary.
Read-Only by Design at the API Layer
Centinel's read-only model is established by the integration architecture, not by a switch that an administrator could later enable. The connection uses the ERP platform's published integration interfaces, similar in purpose to interfaces used by reporting and data export tools. The selected interfaces expose data for retrieval. They do not provide a write route within the Centinel connection.
For SAP S/4HANA, Centinel uses OData APIs for accounting documents. For Oracle ERP Cloud, it uses REST APIs for journal entries. The connection authenticates through a system integration user whose scope is limited to the journal entry data set. It does not access master data, posting workflows, approval queues, or user administration.
The SAP connection requires no ABAP modifications and no SAP transport. Centinel also does not use a write-capable endpoint and does not grant the integration account permission to alter ERP records. The resulting boundary is part of the path itself, rather than a restriction that depends only on the privileges assigned to one account.
Journal Entry Fields in Scope
The integration retrieves the journal entry after it has been posted, including the fields needed to evaluate configured review rules. The complete data scope is limited to the following four areas:
- Document header: posting date, period, document type, company code, and currency
- Line items: account code, amount, debit or credit indicator, cost center, and business area
- Posting user: the user ID that initiated the posting, used to evaluate segregation-of-duty patterns
- Reference field: the document reference string if populated
Centinel does not read customer records, vendor master data, open purchase orders, HR data, fixed asset registers, or other ERP data sets. If sensitive information resides in fields outside the list above, that information is not part of what the integration retrieves.
Changes Centinel Does Not Make
Connecting Centinel does not require an agent on the ERP server or application layer. It does not modify schemas, add tables, create stored procedures, or insert a processing step into the posting workflow. The ERP remains responsible for posting the journal entry and maintaining its own audit trail and ledger.
After a journal entry has been committed to the database, Centinel retrieves a copy through API polling at configurable intervals. The entry therefore exists in the ERP before it is evaluated in Centinel. Centinel keeps a separate copy in its tenanted environment so that the data can be assessed against the rules configured for the customer.
For an SAP team, the scope is comparable to connecting a BI tool or third-party reporting platform. SAP posts the entry, and the integration reads it afterward. The connection does not alter ERP performance, availability, or posting behavior.
How the Data Moves After Posting
Journal entry data reaches Centinel on a near-real-time basis. With SAP S/4HANA OData APIs, entries typically become available within a few minutes of posting. Oracle ERP Cloud has similar latency, depending on the polling interval selected during setup.
This is not a database trigger operating inside the same transaction. The ERP completes the posting, and Centinel collects the entry during the next polling cycle. That timing supports review of relevant posting patterns before the end of the business day or before a period closes, which are the use cases the integration is designed to address.
Journal entry data is held in a separate tenanted data environment and is not shared between customers. Centinel does not retain the upstream documents referenced by ERP entries. Bank statements, invoice images, and contract data are outside the integration scope, leaving only the journal entry fields listed above in the Centinel data set.
Connection Setup for Each ERP
In an SAP S/4HANA environment, setup consists of creating an integration user with the role assignment required for OData API access, supplying the service URL and credentials to Centinel, and confirming connectivity. There is no middleware to install and no SAP transport required.
Oracle ERP Cloud follows the same general pattern. The customer creates an integration user with read scope for journal entries, provides REST API credentials, and validates the connection. Finance operations teams familiar with Oracle integrations can typically complete these steps in a single working session.
For NetSuite, Centinel uses token-based authentication with SuiteAnalytics Connect or a saved search export method. The credentials remain read-only and are scoped to journal entry records. No write access is granted through that connection.
Monitoring Beside ERP Operations
Centinel reports exceptions for finance teams to review. It does not hold entries, block postings, or prevent a journal entry from being committed to the ledger. When Centinel flags an entry, that entry is already present in the ERP. The result is a review event, not a change to the posting.
This separation keeps Centinel outside the posting path. A third-party service should not become a dependency that could affect an ERP close if the service were unavailable. Centinel instead operates as a monitoring layer alongside the ERP, reading entries that the finance team has already posted and identifying those that match configured review criteria.
If a flagged entry requires correction, the finance team makes that correction in the ERP through its normal reversing-entry workflow. Centinel does not initiate corrections and does not write to the ERP.