BC Process Documentation: Why Configuration Without Procedures Creates Operational Risk -

The four types of Finance process documentation every BC environment requires, the compounding cost of missing documentation that Finance pays continuously through the life of the system, and the five process documentation failures that convert a well-configured BC into a fragile Finance operation that breaks whenever a key person is absent.

The Four Types of Process Documentation Every BC Finance Environment Needs

Period-Close Process Narrative

The complete sequence of steps Finance performs from the last day of each period through the distribution of the management pack—in the order they must be performed, with the responsible person, the BC action or path required, the expected output, and the validation criterion that confirms the step is complete before moving to the next.

What it enables: Any Finance team member can run the close following the narrative without the Controller’s involvement. New Finance staff become close-capable within their first month. The auditor can trace the close procedure to BC’s Closing Tasks completion records and confirm the steps were performed in the documented sequence.

Common gap: Most BC Finance teams have BC’s Closing Tasks configured but no written narrative. The Closing Tasks show what was completed and when; they do not explain how each task is performed, what the expected output looks like, or what Finance should do when the output is unexpected. The narrative fills that gap.

Role-Level Desktop Procedures

Step-by-step instructions for each recurring Finance task performed by each Finance role: the AP coordinator’s invoice processing procedure, the AR coordinator’s cash application procedure, the bank reconciliation procedure, the purchase order approval procedure. Each procedure covers the specific BC navigation path, the expected screen behavior at each step, exception handling for common error conditions, and the output Finance produces as evidence of completion.

What it enables: Backup coverage when the primary person is absent. Consistent execution across team members performing the same task. A training resource that reduces time-to-productivity for new hires from months to weeks.

Common gap: Procedures are most often absent for tasks Finance considers routine—the tasks the primary person has performed so many times they no longer consciously think about the steps. Those are precisely the tasks most at risk when the primary person is absent.

Configuration Rationale Documentation

The record of Finance’s configuration decisions and the reasoning behind them: why the chart of accounts has the structure it does, why specific dimension mandatory validation rules are set the way they are, why the vendor posting group has the GL mapping it carries, why the journal approval workflow threshold was set at the specific amount Finance chose.

What it enables: Finance evaluates the impact of proposed configuration changes against the original design intent. When a new implementation partner or IT team member questions a configuration decision, Finance has documented evidence of the reasoning. When a business change requires Finance to revisit a configuration decision, Finance has the context to make the revision intelligently.

Common gap: Configuration rationale is almost never documented during implementation because the timeline is compressed and the decisions seem obvious to the people making them. Three years later, the rationale is not obvious to anyone still on the team, and Finance makes changes without understanding downstream effects on the original design.

Exception and Escalation Playbooks

Documented procedures for Finance situations that do not fit the standard workflow: what Finance does when a bank statement import fails, what happens when the three-way match flags an exception the AP coordinator cannot resolve alone, what the escalation path is when a journal approval workflow is stuck waiting for an approver who is unreachable, what Finance does when a subledger reconciliation produces a discrepancy that cannot be explained within the close timeline.

What it enables: Finance resolves common exceptions without escalating every unusual situation to the Controller. The close is not delayed by exceptions Finance has encountered before and documented the resolution for. New Finance staff understand the boundaries of their authority and the escalation path when they reach them.

Common gap: Exception procedures are typically not documented until after Finance has encountered each exception in live operations—often multiple times. Finance that documents the resolution procedure after the first occurrence builds a playbook incrementally. Finance that waits for recurrence in a live close with a management pack deadline experiences the same delay each time.

The Compounding Cost of Missing Process Documentation

Process Documentation Debt—Where Finance Pays the Cost of Missing Procedures

Five Process Documentation Failures That Break Well-Configured BC Operations

⚠️ Close Narrative Exists in One Person’s Head—Absent Controller Creates a 3-Day Delay

The Controller is the only Finance team member who knows the complete BC close sequence from start to finish. When the Controller is unexpectedly out for five days during a close cycle, the Finance Manager attempts to run the close. She completes the AP subledger reconciliation and the bank reconciliation but does not know the fixed asset depreciation batch must run before the period-end accruals, because the depreciation amount feeds into the accrual calculation. She posts the accruals using last month’s depreciation. She locks the period. When the Controller returns and reviews the financial statements, the depreciation is wrong for the month. The period must be reopened, the entries reversed, the batch run in the correct sequence, and the entries reposted. The correction takes two days and the management pack is delivered three days past its normal date.

Fix: The close narrative must be documented, validated by having a backup Finance team member run a complete close cycle in sandbox using only the documentation as a guide, and confirmed sufficient for any senior Finance team member to use as a standalone reference. If the Finance Manager can run the complete close cycle using the narrative without asking the Controller a single question, the narrative is complete. If she cannot, it is not. Finance schedules this validation exercise annually during a period with low operational pressure.

⚠️ No Exception Procedure for Bank Statement Import Failure—Close Delayed While Finance Figures Out What to Do

The automated bank statement import for the main operating account fails on Day +1 of the close. The import log shows an error Finance has not seen before. The AP coordinator who runs the bank reconciliation has no documented procedure for this situation. She escalates to the Finance Manager, who escalates to IT, who escalates to the implementation partner. The diagnosis—the bank changed a field delimiter in its statement format—takes six hours to reach and one hour to fix. The bank reconciliation that should have been complete by Day +1 afternoon is not complete until Day +2 morning. Every subsequent close step is pushed by one day. The management pack is distributed a day late.

Fix: Bank statement import failure is one of the most predictable close exceptions—it happens to every BC Finance team eventually. Finance documents the exception procedure the first time it occurs: the error log location in BC, the error message categories and their common causes, the navigation path for manually importing a bank statement file, the process for downloading the statement from the bank portal as a fallback, and the escalation path to IT if the import format requires a configuration change. After the first occurrence, the documented procedure prevents the six-hour resolution from repeating. Finance resolves the exception in 30 minutes because the procedure exists.

⚠️ Configuration Rationale Not Documented—Threshold Change Eliminates a Compensating Control Nobody Knew Existed

Finance raises the journal entry approval workflow threshold from £3,000 to £15,000 because the £3,000 threshold generates too many small approval requests during the close. The change is requested by the AP Manager and approved by the Controller without reference to any documentation of why the £3,000 threshold was chosen. What neither manager knows is that the £3,000 threshold was specified by the auditor during the prior year’s audit as a compensating control for an SOD conflict: the AP coordinator can both create and post general journal entries below the threshold—a conflict the auditor accepted only because the £3,000 threshold meant the AP coordinator’s unsupervised posting access was limited to amounts the auditor considered immaterial. After the threshold change, the AP coordinator can post journal entries up to £15,000 without approval. The auditor identifies the change and the eliminated compensating control as a control deficiency that requires a management response.

Fix: Configuration rationale documentation specifies not just what each setting is but why it was chosen, who approved it, and whether it is connected to an audit commitment, an SOD compensating control, or a regulatory requirement. Any configuration change must be reviewed against the rationale documentation before implementation. If the rationale shows the setting is an audit-committed compensating control, the change requires auditor notification before implementation. Finance maintains the rationale document as a living record updated whenever a setting changes.

⚠️ Desktop Procedures Written at Implementation, Never Updated—Staff Follow Outdated Steps That No Longer Match BC

The implementation partner produced desktop procedures during the implementation training phase. Finance filed them in a shared folder. Over 28 months, BC has received four major release waves, the purchase invoice approval workflow has been redesigned once, and BC’s bank reconciliation workspace has been updated by Microsoft with a new matching interface. The desktop procedures have not been updated. New Finance staff trained using the procedures spend their first weeks confused by the discrepancy between the documented steps and the actual system behavior. The AP coordinator who follows the outdated invoice approval procedure does not know a step was added for invoices from EU vendors after a VAT change—a step required to prevent incorrect VAT posting for cross-border purchases. Two EU vendor invoices per month are posted with incorrect VAT for six months before Finance discovers the pattern during a VAT return review.

Fix: Desktop procedures require a maintenance cadence aligned with BC’s change cycle. Finance reviews all desktop procedures at two trigger points: after each major release wave deployment (to identify steps that have changed in the updated system) and after any Finance-initiated configuration change that affects the execution of a documented procedure. The procedure owner—the Finance team member whose role uses the procedure most frequently—is responsible for confirming accuracy after each trigger event. Desktop procedures are Finance-owned documents maintained by Finance’s operational knowledge of what BC actually does in practice.

⚠️ New Finance Hire Takes Five Months to Reach Full Productivity—No Training Infrastructure Exists

A new Finance coordinator joins nine months after go-live. The onboarding plan: shadow the AP Manager for a week, shadow the Controller during the first close, ask questions when confused. No desktop procedures, no close narrative, no documented explanation of why specific configuration choices were made. The new coordinator’s learning is entirely dependent on colleague availability and her own ability to reverse-engineer Finance’s operating logic from BC’s behavior. After five months she is fully functional. Finance has spent approximately 80 hours of senior Finance staff time answering questions that documented procedures would have answered in her first weeks. Finance has also accepted five months of elevated error risk during the period when the coordinator was operating without complete procedural knowledge.

Fix: Finance process documentation is the training infrastructure for Finance roles. When desktop procedures, close narratives, and configuration rationale documents exist, new Finance hires have a structured self-study path that supplements the shadowing experience with written reference material they can consult independently. Finance produces this documentation for each role during the first twelve months post-go-live and maintains it thereafter. The onboarding plan for each new Finance hire includes: read all relevant procedures before first live execution, shadow a close cycle with the procedures as the reference, execute independently with the procedures as backup from the second close cycle forward.

Do This / Don’t Do This

Do This

Document the period-close narrative and validate it by having a backup team member run a full close cycle in sandbox using only the documentation
Write desktop procedures for every recurring Finance task before the primary person performs it ten times—not after
Document configuration rationale at the time of every configuration decision, including who approved it and whether it is connected to an audit commitment
Document exception procedures the first time each exception is encountered and resolved
Review and update all desktop procedures after every major BC release wave and every Finance-initiated configuration change
Use Finance process documentation as the primary training infrastructure for new hires

Don’t Do This

Treat process documentation as something Finance will get to after the system is stable—the close in progress always takes priority over documentation until documentation prevents the close from being disrupted
Allow configuration changes without reviewing rationale documentation for the setting being changed
Keep close-process knowledge in the Controller’s memory as the only reliable source
File implementation-era desktop procedures and consider them current without maintenance review after each release wave
Accept months-long onboarding timelines as normal—they signal missing documentation, not inherent role complexity

Up Next:

Process documentation makes BC operations resilient. The next post addresses the foundational Finance activity that determines whether BC’s live data can be trusted from the first day of operations: BC Data Migration—What Finance Must Validate Before Go-Live—the Finance-owned data migration workstreams that IT cannot complete without Finance’s accounting knowledge, the accuracy validation procedures Finance must run before trusting any migrated data, the opening balance reconciliation Finance must complete before the first transaction posts, and the five data migration failures Finance discovers in reconciliations that should have been run before go-live.

— Bobbi

D365 Functional Architect · Recovering Controller

Thank you for reading!

If a post helped you solve a real problem, share it with a Finance colleague who is in the middle of an implementation or a post-go-live optimization. If you have a topic the blog series did not cover, reach out. There is always one more post worth exploring.

If you are interested in learning more, below are some of my recent posts:

BC Process Documentation: Why Configuration Without Procedures Creates Operational Risk