Accounting Data Integrity and Security
AccuArk's accounting system uses multiple layers of protection to ensure your financial data is accurate, consistent, and secure. This guide explains each safeguard and how they work together.
Double-Entry Validation
Every transaction in AccuArk follows the fundamental accounting rule: total debits must equal total credits. This is enforced at the application level before any data is written to the database.
- When creating a transaction or journal entry, the Save button is disabled until the debit and credit totals match
- The totals bar shows the difference in real time, turning red when there is a discrepancy and green when balanced
- Even if a request were to bypass the UI, the service layer validates balance before committing
This ensures that the accounting equation (Assets = Liabilities + Equity) is always maintained.
Period Locking
AccuArk's accounting period system prevents retroactive changes to closed months. Periods follow a three-state workflow:
- Open — Transactions can be created, edited, and deleted in this period
- Closed — No new transactions can be posted to this period. Existing transactions cannot be edited or deleted. An administrator with the FIN_CLOSE_PERIOD permission can reopen a closed period if corrections are needed.
- Locked — The period is permanently sealed. It cannot be reopened. This is typically used after an audit or tax filing.
When a user attempts to create or edit a transaction with a date that falls in a closed or locked period, AccuArk displays an error and prevents the save. This protects historical financial data from accidental or unauthorized changes.
Complete Audit Trail
Every change to a transaction is recorded in the account_transaction_audit table. The audit trail captures:
- Action type — Created, Modified, or Deleted
- User — Which user made the change
- Timestamp — When the change occurred
- Field-level details — For modifications, the audit records which fields changed, what the old value was, and what the new value is
You can view the audit history for any transaction by selecting it and clicking the Audit History button. This provides a complete chronological record of every change, making it easy to answer questions like “Who changed this amount?” or “When was this transaction created?”
The audit trail is append-only. Audit records cannot be edited or deleted, even by administrators.
Database Constraints
AccuArk uses several database-level constraints to enforce data integrity:
Foreign Key Constraints
- Split records in account_transaction_splits have a foreign key to the parent transaction with CASCADE DELETE. If a parent transaction is removed, all its split lines are automatically removed.
- Recurring journal logs have a foreign key to the recurring journal template. If a template is deleted, its log entries are cascaded.
- Account references on splits and transactions have foreign keys to chart_master, preventing transactions from referencing nonexistent accounts.
CHECK Constraints
- Transaction amounts are constrained to be non-negative. Negative amounts are not allowed; instead, the debit/credit designation determines the direction of the entry.
- This prevents data entry errors where a user might accidentally enter a negative number, which could cause confusion in reports.
DECIMAL(18,2) Precision
All monetary values are stored as DECIMAL(18,2), which provides:
- Exact decimal arithmetic with no floating-point rounding errors
- Up to 16 digits before the decimal point and exactly 2 digits after
- Consistent precision across all calculations, reports, and balances
This is critical for financial data where even a one-cent rounding error can cause a Trial Balance to be out of balance.
Idempotency Keys
The recurring journal processing system uses idempotency keys to prevent duplicate entries. Each time a recurring template generates a journal entry, the system records a unique key based on the template ID and the target date.
If processing runs twice (for example, due to a crash and restart), the system checks for an existing idempotency key before generating the entry. If the key already exists, the entry is skipped. This guarantees that each recurring template produces exactly one entry per scheduled date.
Permission-Based Access Control
AccuArk uses 16 FIN_* permission codes to control access to accounting features:
| Permission | Description |
|---|---|
| FIN_VIEW_TRANSACTIONS | View account transactions |
| FIN_CREATE_TRANSACTION | Create new transactions and journal entries |
| FIN_EDIT_TRANSACTION | Edit existing transactions |
| FIN_DELETE_TRANSACTION | Delete transactions |
| FIN_VIEW_COA | View the Chart of Accounts |
| FIN_MANAGE_COA | Create, edit, and delete accounts |
| FIN_MANAGE_ACCOUNT_TYPES | Manage account types and classes |
| FIN_REPAIR_BALANCES | Run the Repair Balances utility |
| FIN_VIEW_REPORTS | View financial reports |
| FIN_VIEW_BILLS | View bills and AP data |
| FIN_CREATE_BILL | Create new bills |
| FIN_CANCEL_BILL | Cancel existing bills |
| FIN_MANAGE_BILL_SCHEDULE | Manage bill payment schedules |
| FIN_PAY_BILLS | Process bill payments |
| FIN_CLOSE_PERIOD | Open, close, and lock accounting periods |
| FIN_MANAGE_RECURRING | Manage recurring journal templates |
Each permission is assigned to roles (Super Admin, Location Admin, Manager, Accountant, etc.), and users inherit permissions from their assigned role. This ensures that employees only have access to the accounting functions they need.
Location-Based Data Isolation
In addition to permission-based access, AccuArk isolates accounting data by location. Users can only see transactions and balances for locations they have been granted access to through the user_location_access table. This means:
- A store manager sees only their store's financial data
- A regional manager sees data for their assigned locations
- A controller or owner sees all locations
This two-layer security model (permissions plus location access) ensures that sensitive financial information is only visible to authorized personnel at the appropriate scope.