Audit Prepared?By?Client (PBC) repeats; SharePoint?Workiva portal assembled permissioned evidence with Finance sign?off

Overview

A manufacturing conglomerate’s audit Prepared?By?Client (PBC) process generated repeated requests because supporting documents were scattered across sites and folders. Finance tracked requests in spreadsheets, evidence lived in SharePoint and Workiva, and sensitive items required ad hoc approvals. Intelligex built a PBC portal that integrated with SharePoint and Workiva, added permission?aware search to assemble evidence packs, and assigned owners and due dates with Finance approvals on sensitive items. Auditors received consistent packages, repeat asks declined, and status visibility improved for all stakeholders—without replacing repositories or the existing close and reporting stack.

Client Profile

• Industry: Diversified manufacturing (multi?division, multi?entity)
• Company size (range): Enterprise finance organization with regional controllership teams
• Stage: SharePoint for document management, Workiva for connected reporting, spreadsheets and email for PBC coordination
• Department owner: Finance & Accounting (Corporate Controllership)
• Other stakeholders: Regional Controllers, Internal Audit, External Auditors, IT/Information Security, Legal, Tax, Treasury, FP&A

The Challenge

The audit PBC list arrived as spreadsheets or portal exports that did not align to the company’s account structure or reporting packs. Account owners copied requests into trackers, hunted for evidence in SharePoint sites and legacy drives, and uploaded files to folders with inconsistent naming. Workiva contained tie?outs and roll?forwards, but links to journal details and source contracts were not embedded in a single place. When auditors asked follow?up questions, owners rebuilt packets from scratch.

Permissions and sensitivity complicated the process. Certain requests involved payroll, legal agreements, or supplier pricing. Redaction and approvals were handled via email, and over?sharing was a risk. Status lived in disparate trackers, so leaders could not see blockers or aging items across entities. External auditors submitted repeat requests because versions drifted or evidence wasn’t complete, and closing the loop consumed time that should have been spent on substantive review.

Why It Was Happening

Root causes were fragmented evidence and ungoverned workflows. SharePoint sites varied by region and function with different metadata, so search returned inconsistent results. Workiva narratives and tie?outs were not systematically referenced in PBC packets, and there was no canonical request taxonomy mapping to accounts, processes, and owners. Approvals for sensitive items lived in inboxes without a durable link to the delivered evidence. Without a central orchestration layer, ownership was unclear, and both auditors and Finance retraced steps multiple times.

Roles were defined but not enforced by tooling. Controllership coordinated the list, Internal Audit checked completeness, IT managed repositories, and External Auditors requested updates through their portal. None of these guaranteed that every request had a single owner, a due date, a versioned packet, and a permission?appropriate path from source to delivery.

The Solution

Intelligex delivered a PBC orchestration portal that sat on top of existing repositories. Requests were normalized to a standard taxonomy, owners and due dates were assigned, and evidence packs were assembled via permission?aware search across SharePoint and direct references to Workiva artifacts. Sensitive items flowed through a review gate with Finance approval and optional redaction before release. Each delivered packet was versioned, watermarked, and linked to its sources, and auditors interacted with a filtered view that exposed only approved artifacts. The solution leveraged Microsoft SharePoint integration patterns and connected reporting practices in Workiva.

• Integrations: SharePoint sites and libraries for evidence retrieval; Workiva tie?outs and supporting schedules; optional read?only GL and journal metadata to anchor requests; SSO for role?based access; auditor portal view with scoped permissions.
• Request taxonomy and templates: Standard categories by process (revenue, inventory, payroll, tax, treasury, fixed assets), mapped to accounts and owners with due dates and required artifacts.
• Permission?aware search: Queries across SharePoint libraries that respected site?level access and metadata; direct linking to existing Workiva documents; evidence assembly without duplicating files unnecessarily.
• Review gates for sensitive items: Maker?checker approval for items involving personal, legal, or pricing information; redaction and watermarking options; decision logs attached to the request.
• Packet builder and versioning: Exported, consistent folders or zip bundles with manifest files; immutable version history and linkbacks to sources.
• Dashboards and SLA tracking: Request aging, blockers by entity/process, rework due to missing artifacts, and audit response posture; alerts to owners and reviewers.
• Audit trail and permissions: Role?based access to requests, artifacts, and approvals; immutable logs of search results, selections, redactions, releases, and auditor downloads.

Implementation

• Discovery: Mapped current PBC intake, common request types, and owners; inventoried SharePoint sites, metadata, and Workiva document structures; reviewed prior audit comments on missing or inconsistent support; identified sensitive categories and approval chains.
• Design: Defined the request taxonomy and ownership rules; modeled metadata needed for reliable search; specified packet structure, manifest details, and watermark standards; designed sensitive?item review gates and redaction patterns; planned dashboards and auditor access scopes.
• Build: Implemented SharePoint connectors and permission?aware search; integrated Workiva linking for tie?outs and supporting schedules; built the request assignment engine and SLA tracking; developed packet builder with manifests and versioning; added approval workflows for sensitive items; assembled dashboards and auditor portal views.
• Testing/QA: Ran in shadow mode: processed a live PBC list while teams continued existing methods; compared delivered packets to auditor feedback; tuned search metadata and templates; exercised sensitive?item approvals with Finance, Legal, and Information Security.
• Rollout: Enabled the portal for core audit cycles and selected entities first; retained spreadsheet trackers as a controlled fallback; expanded coverage as templates stabilized and permissions were confirmed; opened auditor views after successful internal cycles.
• Training/hand?off: Delivered sessions for Controllers, process owners, Internal Audit, and External Audit on assigning requests, assembling packets, approving sensitive items, and using dashboards; updated SOPs for evidence naming and metadata; transferred ownership of templates, gates, and dashboards to Controllership under change control.
• Human?in?the?loop review: Established a cadence to refine templates, adjust sensitivity classifications, and review repeat asks; decisions recorded with rationale and effective dates.

Results

Auditors received complete, consistent packages tied to the request taxonomy. Evidence packs referenced the same SharePoint and Workiva sources the business used, with manifests and watermarks to show provenance. Owners and due dates were clear, and dashboards showed where bottlenecks formed so leaders could intervene before aging items accumulated. Repeat asks declined because packets were assembled and versioned against standards rather than ad hoc.

Sensitive information flowed under control. Items that required redaction or special approval followed a defined path, with Finance sign?off and rationale attached to the packet. External auditors accessed only approved artifacts through a scoped view, and every download and change was logged. The repositories and reporting tools remained in place; the addition was a governed orchestration layer that made PBC delivery consistent and traceable.

What Changed for the Team

• Before: PBC trackers lived in spreadsheets and email threads. After: A portal assigned owners and due dates with dashboards for posture and blockers.
• Before: Evidence was searched manually across sites. After: Permission?aware search assembled packets from SharePoint and linked Workiva artifacts.
• Before: Sensitive items were handled via ad hoc emails. After: Maker?checker approvals and redaction gates governed release.
• Before: Repeat requests were common. After: Standard templates and manifests reduced rework and confusion.
• Before: Version drift created extra cycles. After: Packets were versioned with watermarks and source linkbacks.
• Before: Auditor access varied by team. After: A scoped auditor view exposed only approved artifacts with full logging.

Key Takeaways

• Centralize PBC orchestration; assign owners, due dates, and templates in one place.
• Integrate with existing repositories; use permission?aware search and linking rather than duplicating evidence.
• Standardize packets; manifests, watermarks, and versioning reduce repeat asks.
• Govern sensitive items; maker?checker reviews and redaction protect data while meeting audit needs.
• Make posture visible; dashboards for aging and blockers let leaders intervene early.
• Integrate, don’t replace; bind SharePoint and Workiva with a governed workflow that auditors can trust.

FAQ

What tools did this integrate with? The portal connected to Microsoft SharePoint for evidence retrieval and to Workiva for tie?outs and supporting schedules. It referenced GL and journal metadata from the ERP for context and used SSO for role?based access. External auditors accessed a scoped view of approved packets through the same portal.

How did you handle quality control and governance? Request templates, sensitivity classifications, and approval flows lived under Controllership change control with effective dates. Sensitive items required maker?checker approval with rationale, and redaction and watermark standards were enforced by the portal. Every search, selection, approval, packet build, and auditor download was immutably logged.

How did you roll this out without disruption? The portal ran in shadow mode first, producing draft packets while teams continued using trackers and email. Results were compared to auditor feedback, and metadata and templates were tuned. Rollout began with selected entities and audit areas, then expanded once permissions and packet standards proved reliable. Spreadsheet trackers remained as a controlled fallback during early cycles.

How were sensitive documents controlled? Requests tagged as sensitive flowed to a review gate where Finance (and Legal or Information Security when needed) approved release, requested redaction, or routed for alternate support. The final packet contained only approved artifacts, watermarked and logged, and the approval history stayed attached to the request.

How did you reduce repeat requests from auditors? Each packet followed a standard template with a manifest that listed artifacts, source locations, and Workiva linkbacks. Versioning ensured the latest packet superseded prior deliveries, and auditors viewed only the most recent, approved version through a scoped portal. Consistent structure and provenance reduced the need for follow?ups.

How were permissions and access managed? The portal respected SharePoint site permissions for evidence retrieval and layered role?based access for requests, approvals, and auditor views. SSO enforced identity, and the system logged who saw what and when. No changes to SharePoint site structure were required beyond adding metadata to improve search reliability.