Audit Trail and Change Log Compliance

The problem auditors actually put in writing

An auditor rarely asks "do you have change logs?" They ask a much narrower question: who changed the bank account on this supplier, on which date, from what value to what value, and who approved it? Answering that in a standard SAP Business One install means opening the Change Log window on one document at a time, reading a row-versus-row comparison that only exists for objects SAP chose to log, and hoping nobody edited the record through the DI API or a direct SQL update. There is no single place to query it, no way to export a date range, no record of who merely looked at payroll or customer bank details, and no alert when a payment-critical field moves.

That gap becomes expensive in three situations: an external financial audit that needs evidence of segregation of duties, an internal fraud investigation after a payment goes to the wrong account, and any compliance regime — SOX-style internal controls, ISO 27001, GDPR data-subject requests — that requires you to demonstrate control rather than assert it. In each case the answer has to be reproducible by someone other than you.

What ECOSIRE builds

ECOSIRE builds a SAP Business One add-on that turns change history into a first-class, queryable, exportable dataset. Nothing here is a shrink-wrapped product waiting for a download — the solution is scoped against your database, your document types and your regulator, then built and installed for you.

Capture layer

The capture layer is deliberately belt-and-braces, because a log that only sees one entry path is not evidence. We combine:

• Service Layer and DI API interception for changes that flow through integrations, portals and our own screens, recording the payload before and after the update on Business Partners, Items, Sales Orders, A/R and A/P Invoices, Purchase Orders, Journal Entries and Payments.
• Database-level triggers on the tables you designate as sensitive (OCRD, CRD1, OITM, OJDT, JDT1, OVPM/ORCT and their child tables), so a change made outside the application — a direct UPDATE, a data-migration script, a third-party tool — still lands in the trail. Trigger scope is agreed with you and kept narrow so transactional throughput is not affected.
• UI-level hooks through the SAP Business One SDK for the events that have no data footprint at all: opening a form, running a query, printing a Crystal Report containing bank details.

Every captured event writes to a set of User-Defined Tables (UDTs) modelled as an append-only ledger: event id, timestamp, database user, B1 user code, object type, DocEntry/CardCode key, field name, old value, new value, entry channel (UI / Service Layer / DI API / direct SQL), workstation or client IP, and an optional business reason captured from the operator.

Integrity and retention

Audit evidence is only as good as its resistance to tampering. Each log row carries a hash chained to the previous row for that object, so a deleted or edited row breaks the chain and is detectable by a verification routine you can run on demand. Log tables are write-restricted at the database-role level, retention periods are configurable per object class, and archived periods can be sealed to a separate schema or file export while remaining queryable through the add-on.

Sensitive-field watch list and alerting

You nominate the fields that matter — supplier bank account and IBAN, customer credit limit, item price list entries, payment terms, tax registration numbers, approval-template membership. Changes to a watched field raise an immediate notification through the SAP Business One internal messaging/alerts framework and, where you want it, an email to a control owner. The alert carries old value, new value, actor and document context, so a control owner can act without opening the client.

Approvals, segregation of duties and reporting

Where your controls require it, a watched change can be routed into an SAP Business One approval procedure before it is allowed to persist, and the approval decision is written into the same trail as the change itself. On top of the ledger we build the reporting layer auditors actually use: a searchable change-browser inside the B1 client (filter by user, date range, object, field, or value), Crystal Reports templates for the standard evidence packs, and scheduled exports to CSV or PDF for a period so evidence can be handed over without giving an auditor database access.

Who this is for

Finance teams operating under external audit; groups running multiple company databases who need one consistent control story; organisations that have suffered — or fear — a bank-detail fraud; and IT teams that need to prove who has been touching master data through integrations. It is equally relevant where several third-party tools write into B1 through the Service Layer and nobody can currently say which one made a change.

Technical framing

The add-on is built for SAP Business One 10.0 on both Microsoft SQL Server and SAP HANA, on-premise or cloud-hosted, using the Service Layer (REST) and the DI API for data access, UDFs/UDTs/UDOs for the log model and configuration, the B1 SDK for UI events and the standard alerts and approval-procedure frameworks for notification and control. Delivery is per-tenant: your configuration, your watch list, your retention rules.

How delivery works

1. Scoping call. We walk through the objects and fields your auditor or control framework actually names, your entry channels (client, Service Layer integrations, portals, data loads), your retention obligation and your reporting format. We agree what is in scope and — just as importantly — what is not, because logging everything is how audit trails become unusable. 2. Fixed quote. You receive a written scope and a fixed price before any development starts. If the scope changes later, so does the quote, in writing. 3. Build. ECOSIRE develops the add-on against your version and database platform. Lead time is typically one working week depending on how many objects and entry channels are in scope. 4. Install in your test company. We install into your test/sandbox company database first, load the watch list, and run a change-and-verify pass with your team against real scenarios so you can see the evidence output before it touches production. 5. Promote to production. After your sign-off we install into the production company database, configure roles and retention, and hand over the operational runbook. 6. Support window. A defined post-go-live support period is included with the quote, covering defects, configuration adjustments and questions from your auditors about how the evidence is produced.