A Shared-Service Accountant Sees Another Legal Entity and High-Value Journals Auto-Approve
Arboria Group's shared-service center supports 240 General Ledger users across LE-01, LE-02, and LE-03. User J. Park is a General Accountant who should only enter and post journals for LE-01. In testing, she was able to view and post a journal to LE-03. Her job role is provisioned with the data access set DAS_SHARED, which grants read and write access to all three ledgers, and segment value security on cost centers is not implemented. In a separate finding, the controller discovered that journals above the 25,000 USD approval threshold have been auto-approving for weeks. Journal Approval is enabled on the ledger, an approval rule for amounts over 25,000 exists, and the preparers hold approval limits high enough to approve their own entries. The controller wants both issues fixed before the next close without disrupting the 240 users.
1. Diagnose why J. Park can post to LE-03 and describe a least-privilege redesign that can be deployed without rebuilding every user's access.
Read the worked answer
Access is granted through the data access set attached to the role, not through the ledger itself. DAS_SHARED gives read and write on all three ledgers, so any user holding that role inherits LE-03 write access regardless of job title. Segment value security is not a substitute here because it restricts values within a ledger, not access to the ledger. The redesign is to create scoped data access sets, for example DAS_LE01 only, with read and write on LE-01 and no access to the other ledgers, and assign each user the data access set matching their entity. Where users genuinely need cross-entity visibility for reporting, give read-only access through a separate reporting role rather than adding write access to the transactional role. Use the security console's test or simulate feature to confirm effective access for a sample user before rollout, then migrate users in groups by entity. Keep DAS_SHARED only for the small group that truly needs it, and review its membership quarterly.
2. Why are journals over 25,000 auto-approving despite the rule, and what should be checked and changed?
Read the worked answer
Several conditions can produce this. First, the ledger option that allows the preparer to approve their own journal, when enabled and the preparer's limit exceeds the amount, lets the entry clear without a separate approver. Second, the approval rule may not be matching the actual transaction: check the ledger, journal source, and category in the rule conditions, and confirm the rule is active and effective for the current date. Third, the amount condition may be evaluating a different amount than expected, such as entered versus accounted amount, so a foreign-currency journal can slip under the threshold. Fourth, the preparers may belong to an approval group whose aggregate limit is high enough to self-clear. Review the approval history on a sample journal to see which path it took, then disable preparer approval if segregation of duties requires an independent approver, correct the rule conditions and amount basis, and test with a journal just below and just above the threshold. Communicate the change before close so preparers are not surprised by pending approvals.
3. The controller wants an audit trail of who changed access and approvals. What should you put in place?
Read the worked answer
Enable and use the security and approval audit facilities rather than relying on memory. In the security console, review role and data access set assignments and their change history, and export a baseline of who holds which data access set before and after the redesign. For approvals, use the approval history and transaction console to capture who approved what, when, and under which rule, and retain that evidence with the close package. Schedule a recurring review, at minimum quarterly, comparing current assignments against the HR roster and flagging anyone with access to more than one ledger without a documented business reason. Record the review itself, including who performed it and what exceptions were accepted. This turns the two findings into a controlled process and gives the auditor evidence that the fixes were not just one-time cleanups.