An architectural guide for integrating authority management with HRIS, ERP/procurement, and identity systems so approvals are consistent and auditable.
Definition: Single source of truth for authority. A designated system of record that owns the authority rules (the matrix and delegation records), while other systems consume those rules or validate against them, so that approvals, signatures, and access controls across every platform reflect the same governed data.
Definition: Integration-driven authority drift. The condition that emerges when authority rules defined in one system (the policy or matrix) diverge from the enforcement of those rules in other systems (the ERP, the procurement tool, the IAM platform), producing situations where the same action is authorized in one system and unauthorized in another.
Most authority problems are not policy problems. They are integration problems. When HR systems, approval workflows, and access controls each carry a different view of who is allowed to do what, drift is not a risk but a certainty. The EY and Society for Corporate Governance Delegation Edge study found that roughly 90 percent of companies maintain delegation of authority policies, but training and enforcement remain their two largest challenges, with 36 percent identifying training as the single greatest difficulty and 54 percent documenting authority through both a board memo and a formal matrix. The policy exists; the enforcement does not.
McKinsey's research on decision-making frames the same gap from a different angle: growing organizational complexity has clouded accountabilities, making it harder for leaders to delegate decisions cleanly. The West Monroe 2026 Speed Wins research quantifies the cost: 73 percent of C-Suite leaders believe halving decision cycle time would unlock at least five percent in additional revenue, while each additional request for analysis adds an average of three weeks of delay. Integration-driven delay is a direct contributor to both. On the compliance side, the KPMG 2025 SOX Survey found that 40 percent of compliance teams still rely on spreadsheets as their authority system of record and only 17 percent of controls are automated, down from 21 percent just two years earlier. Spending on compliance is rising while automation is falling.
A single source of truth for authority directly addresses these failures by creating one place where authority rules are defined and from which every other system derives its enforcement logic. This article defines what that means architecturally, lays out the three systems that must be connected, distinguishes authority governance from identity governance and GRC, describes the integration pattern that works, and closes on the design decisions that determine whether an integration succeeds or creates a new layer of drift.
A single source of truth for authority is not a single system that stores everything. It is an architectural pattern with three properties: one place owns the authority rules, other systems consume or validate against those rules rather than maintaining independent authority logic, and every change is versioned with clear effective dates and propagation semantics.
The distinction between "source of truth" and "master" matters for integration architects. A master is typically a unidirectional authority on record structure (employee master, vendor master). A source of truth is bidirectional: it owns the record AND it is the reference point that downstream systems validate against at runtime or at evaluation time. The authority matrix is a source of truth precisely because ERP approval workflows, procurement routing, and IAM entitlements all need to ask it the same question, "is this actor authorized for this action?", and get the same answer.
This architecture applies equally to human and non-human actors. The same integration pattern that supports a VP approving a purchase order also supports an AI agent executing bounded procurement decisions within its delegated authority. For the governance model that extends authority to AI agents, see agentic authority management. The integration pattern is identical; what changes is what sits at the end of the delegation record.
Every authority integration is ultimately a triangle between three system categories. The table below summarizes what each category owns, its role in authority management, and the typical integration pattern.
The HRIS is the source of organizational reality. It owns employment status, role, reporting line, department, cost center, and entity assignment. When a person is promoted, transferred, placed on leave, or terminated, the authority system needs to know within hours, not quarters. The EY study's finding that 36 percent of companies identify training as their greatest DOA challenge is largely a symptom of missing HRIS integration: in organizations where role changes do not automatically trigger authority reviews, delegations become stale faster than training can correct.
The ERP, procurement, and CLM systems are where approvals actually happen. A procurement manager approves a purchase order in the procurement platform. A contract is signed in the CLM. A payment is released in the ERP. These systems enforce authority at the moment of action. If their enforcement logic diverges from the authority matrix, you have a control design failure that KPMG's material weakness data shows is now one of the fastest-growing categories of audit finding. Segregation of duties and control design issues have climbed from 34 percent of material weakness disclosures in FY21 to 55 percent in FY23 and continue rising.
Identity and access management platforms govern the execution boundary: can this actor reach this system at all, and can they invoke this API. IAM is necessary for authority but not sufficient. An actor with legitimate IAM access to a procurement system can still lack the delegated authority to commit the organization to a specific contract at a specific threshold. When IAM is treated as a substitute for authority governance, the organization ends up with a permissions surface that is too large for its actual authority posture.
When the three are not connected, you get the full spectrum of authority failures: HR role changes that never propagate to delegations, workflow rules that diverge from the matrix, and system entitlements that persist long after the underlying authority has been revoked.
The most common architectural error in authority integration is treating an identity platform or a GRC platform as if it answers the authority question. It does not. Each layer answers a different question, and all three are necessary for a complete governance stack.
Identity governance platforms answer "can this user or agent access this system?" Vendors in this category include Okta, SailPoint, Saviynt, and Microsoft Entra. They are essential for enforcing the boundary between who has the technical capability to invoke a system and who does not. They do not answer what that actor is permitted to do once inside the system. Research on agentic AI governance makes this distinction explicit. The OWASP Foundation's 2025 Top 10 for Large Language Model Applications elevated "Excessive Agency" to the sixth position on its risk list precisely because identity-layer controls are insufficient to prevent unauthorized actions by actors that have legitimate access but lack bounded authority.
GRC platforms answer "are we compliant with our controls, after the fact?" Vendors in this category include ServiceNow, Diligent, and AuditBoard. They are essential for audit evidence production, risk assessment, and regulatory reporting. They operate on a review cadence rather than at runtime. The Grand View Research GRC market report estimates the segment at $62.9 billion in 2024, growing to roughly $135 billion by 2030, reflecting the category's breadth. But GRC platforms consume authority data rather than produce it. They audit what decisions were authorized; they do not decide at runtime whether a specific action should be authorized.
Authority governance answers a distinct third question: "Is this specific actor authorized to take this specific action at this specific threshold, on this specific entity, on this specific date?" This is the runtime question that neither identity platforms nor GRC platforms answer. It is the question an ERP approval workflow needs answered before routing, the question an agent runtime needs answered before executing, and the question an audit needs answered retrospectively to prove a past decision was legitimate.
The three layers are complementary, not substitutes. Identity is necessary but not sufficient. GRC is necessary but not timely. Authority governance is the runtime-authoritative record that makes the other two layers work as designed. Research from MIT Media Lab, Google DeepMind, and Palo Alto Networks on agentic AI governance all converge on the same conclusion: agentic governance is fundamentally a delegation-of-authority problem, distinct from identity or access control.
The five-step pattern below is the sequence most successful authority integrations follow. Order matters: each step depends on the output of the step before it, and skipping steps creates integration debt that is more expensive to remove than to avoid.
The EY study's finding that 90 percent of companies maintain DOA policies but struggle with enforcement is largely a symptom of organizations completing step 2 (defining rules) without step 3 (exposing them to other systems) or step 4 (enforcing them in workflows). The matrix exists in a document; the enforcement lives in each system's independent approval configuration; the two drift apart within months of the last board review. A practical DOA policy specifies not only the rules but also the integration contract: how the rules flow into enforcement.
Typical implementation timelines are four to eight weeks for HRIS ingestion, eight to twelve weeks for ERP and workflow integration, and twelve to sixteen weeks for bidirectional IAM reconciliation. Organizations that attempt all three simultaneously invariably underestimate the HRIS data quality work required to support the other two.
Four design decisions determine whether an integration produces a clean single source of truth or a new layer of drift. Each deserves an explicit answer in the integration's architecture document before any code is written.
Granularity. Manage authority at the role level, the person level, or both. The honest answer is usually both: role-level authority provides the stable default that survives personnel changes, while person-level overrides handle temporary coverage, project-specific delegations, and the exceptions that every real organization generates. Aptly's Decisions Register owns the rule-level structure; the Delegations Register owns the person-level grants.
Effective dating. Every delegation record should carry a start date, an end date or auto-expiry interval, and a version history. Future-dated authority (scheduled promotions, planned coverage) should be first-class. Retroactive authority (rare, and suspicious) should be flagged and require elevated approval. The R6 guidance on time-bound defaults for AI agents applies identically to human delegations: a delegation without an expiry is a delegation that will outlive its original business context.
Exception handling. Exceptions should create evidence, not bypass it. When a human or system deviates from the authority rules, the deviation should be recorded with the actor, the rationale, the approving party, and the date. The SOX audit evidence package requirement for as-of authority proof is most often broken by informal exceptions that leave no trail.
Failure modes. When a downstream system cannot validate authority because the authority service is unavailable, the table below summarizes the three acceptable responses. Picking the right mode for each action class is a design decision, not a runtime decision.
Start with the HRIS integration. When HR role changes automatically trigger authority reviews, you eliminate the single largest source of stale delegations and create the clean, current authority baseline that all downstream integrations will depend on. The ERP and workflow integrations can follow once that baseline exists. Organizations that invert this sequence, starting with ERP integration against a stale authority matrix, invariably spend the savings from automation on reconciliation work for the drift the integration did not eliminate.
The following anti-patterns appear repeatedly in integration projects that fail to produce a clean single source of truth. Each has a fingerprint that is easy to recognize once you know what to look for.
Use this checklist to assess whether your current authority integration posture meets the minimum bar for a single source of truth.
Aptly is designed to be the authority system of record that the integration architecture above requires. It owns the authority rules and delegation records, exposes them to other systems, and versions every change with effective dates and audit evidence.
The platform maps directly to the three capabilities this article establishes. First, Aptly owns the authority rules through its Decisions Register (rule-level structure) and Delegations Register (person-level grants), with the same system supporting AI agent delegations as a first-class entity. Second, Aptly integrates with HRIS and operational systems through standard APIs and event streams, so role changes propagate into authority reviews and authority decisions propagate into workflow routing. Third, Aptly versions every authority change with effective dates, approver, rationale, and evidence, so reconstruction of past authority state is a record lookup rather than an audit-reconstruction exercise.
The architectural position matters. Aptly is not a replacement for an identity platform or a GRC platform. It sits between them and makes both more effective: identity governance decides who can reach the system, authority governance decides what they can do once inside, and GRC audits the accumulated evidence. For the operational patterns that connect authority data to downstream approvals, the guide on embedding authority checks into workflows covers the runtime decision pattern. For the change management discipline that keeps authority data current, see the authority change management playbook. For the sync maintenance pattern, see the guide on keeping delegations and signature authority in sync.
HRIS integration. Role changes, terminations, and reorganizations are the most frequent triggers for authority updates. Connecting HRIS events to authority review workflows eliminates the single largest source of stale delegations and creates the clean baseline required for downstream system integrations. Organizations that invert this sequence, starting with ERP integration against a stale authority matrix, typically reconcile for longer than they integrated.
Yes. The authority system of record does not replace the ERP, procurement, CLM, or identity systems. It sits alongside them as the canonical source for who can approve and execute what. Other systems consume authority data through APIs, exports, or event-driven updates rather than maintaining their own independent authority logic. The architectural pattern is publish-subscribe, not rip-and-replace.
Design fail-safe behavior upfront per action class. For high-risk actions such as payments or contract signatures, a hard block that prevents action until validation is restored is usually appropriate. For moderate-risk actions, a soft stop that permits execution with additional escalation and evidence requirements preserves business continuity. For lower-risk actions, a monitor-only mode that flags exceptions for post-facto review may suffice. The decision is architectural, not operational, and it should be made in the integration design document rather than at runtime.
At minimum: employment status (active, terminated, on leave), current role and title, reporting line, department and cost center, legal entity assignment, and location. Role change events (promotions, transfers, leaves, terminations) should flow as real-time or near-real-time events to trigger authority reviews automatically. Bulk batch updates are acceptable for back-population but should not be the production integration pattern.
Enforce at the integration layer, not through documentation. Every workflow system that enforces approvals should call the authority API at decision time rather than maintaining its own threshold configuration. When workflow configurations and authority rules are maintained independently, drift is not a risk but a certainty. The technical pattern is to treat the authority API as the sole producer of authorization verdicts and the workflow systems as consumers that implement the verdict without re-litigating it.
At minimum, the API should accept an action descriptor (actor identity, action type, entity, amount, date) and return an authorization verdict (permitted, denied, conditional, escalate) with the specific delegation record and effective dates that produced the verdict. The response becomes part of the audit evidence for the downstream workflow. Caching is acceptable for non-time-sensitive actions but should respect the effective-date semantics of the authority record.
IAM platforms answer whether an actor can access a system. Authority governance answers whether that actor is authorized to take a specific business action at a specific threshold on a specific entity on a specific date. The two layers are complementary, not substitutes. An actor with valid IAM access to a procurement system may still lack the delegated authority to commit the organization to a specific contract; an actor with delegated authority still needs IAM access to execute in the system where the action happens. A complete governance stack includes both.
Every authority decision (grant, modification, revocation, invocation) should create a versioned record with the actor, the triggering event, the approver, the effective dates, and the rationale. Every authority API call from a workflow system should log the action descriptor, the verdict, and the delegation record that produced it. These two evidence streams, taken together, satisfy the as-of authority proof requirement that auditors apply to every sampled transaction. For the specific evidence elements auditors expect, see the DOA and SOX internal controls guide.
Connect with our team for a discovery session to learn more about how Aptly can help within your organization. If you are already a client and need support, contact us here.
