Month-End Close Automation

The problem

Most finance teams run the month-end close on a spreadsheet that lives outside the ERP. The spreadsheet lists tasks, owners and due dates, but it knows nothing about what is actually happening inside Dynamics 365 Finance & Operations. Someone has to open a form, run an inquiry, eyeball a balance and then go back to the spreadsheet and mark a row green. When a close spans several legal entities, the controller ends up chasing status by email while the close calendar drifts.

The standard financial period close workspace in F&O gives you a task list, resources and a period status per legal entity. What it does not give you is dependency enforcement, subledger readiness gates driven from live balances, reconciliation variance tracking, or an evidence trail that an auditor can follow without asking for screenshots. That gap is where the extra days in your close live.

What ECOSIRE builds

This is a build-to-order X++ extension package for Dynamics 365 Finance and Supply Chain Management. Nothing here is a pre-built download — we scope your close calendar, quote a fixed price, then build and deliver the solution into your own LCS pipeline.

Close calendar and task engine

We build a close template model: task groups, individual tasks, owners resolved from HcmWorker or system users, offsets expressed in working days relative to period end, and per-legal-entity applicability. Templates generate a dated close instance for each period. Tasks carry predecessors, so a task cannot be started until its dependencies are complete — no more "someone closed AP before the last invoice batch posted".

Tasks can be manual (a person ticks it, optionally attaching a document through DocuRef) or automated. Automated tasks execute a registered close action in the batch framework: run a specific inventory recalculation, trigger a foreign-currency revaluation, execute a consolidation-eligible balance check, or call a validation routine you nominate. Batch jobs report their outcome straight back into the task record, including run duration and any exception text.

Subledger readiness checks

We implement a readiness evaluator that queries live F&O data before it lets a subledger be declared ready. Typical checks we build:

• Unposted journals remaining in LedgerJournalTable by journal name and period
• Vendor and customer invoices in an approval or pending-posting state
• Product receipts received but not invoiced, and inventory transactions in a physical-only state
• Fixed asset depreciation proposals not yet posted for the period
• Bank statements not reconciled, and bank account balances that diverge from the ledger
• Subledger journal entries not transferred to General ledger

Each check returns a count and a drill-through so the owner can jump directly to the offending records rather than hunting for them.

Reconciliation status across entities

We build a reconciliation register that pairs a ledger account (or ledger dimension combination) with a supporting balance source, computes the variance from live data, and records the explanation, preparer, reviewer and supporting attachment. Balances come from the ledger via the standard balance APIs and from the subledger tables, evaluated per legal entity and per fiscal period. Variances outside your tolerance are flagged; matched reconciliations are locked and stamped.

Multi-entity close cockpit

A workspace shows the close across every legal entity in scope: overall percent complete, tasks overdue, subledgers still open, reconciliations outstanding and the critical path. Controllers see a single grid instead of a mailbox. Drill into an entity and you get its task list, readiness panel and reconciliation register.

Workflow, notifications and audit

Sign-offs run on the native F&O workflow engine, so approvals honour your existing hierarchies, delegation and work item queues. Notifications reuse the standard alert framework and email. Every status change writes an immutable log row: who, when, from which state, and which batch job or user action drove it. Period status changes on LedgerFiscalCalendarPeriod can be gated so a period cannot be moved to On hold or Permanently closed while blocking tasks remain open.

Data and integration surface

We expose data entities for close templates, close instances, tasks, readiness results and reconciliations, so everything is available through the Data management framework and OData. That means your close status can be pulled into Power BI, surfaced in a Power Platform app for reviewers who do not have an F&O licence, or exported for an auditor. Where you already use Dual-write, we can align the entity keys so close status is visible alongside Dataverse-side processes.

Who this is for

Group controllers running a multi-entity, multi-currency close. Finance shared-service teams who own the close calendar for several operating companies. Internal audit and SOX teams who need reconciliation evidence attached to the record rather than stored in a shared drive. Finance systems owners who are tired of maintaining a close spreadsheet that nobody trusts by day three.

How delivery works

1. Scoping call. We walk your current close calendar, the legal entities in scope, your subledger set, your reconciliation list and your F&O version and update cadence. We look at what you already do in the standard financial period close workspace so we extend rather than duplicate it. 2. Fixed quote. You receive a written scope with the task model, the readiness checks, the reconciliation set, the workspace design and the delivery timeline. The price is fixed against that scope. Change requests are quoted separately. 3. Build. We develop the solution as X++ extensions in a dedicated model — extension classes, chain of command, table and form extensions, and event handlers. No overlayering, so your update cadence is not compromised. Deployable packages are produced from a clean build. 4. Install in test. We deploy the package to your sandbox through your LCS pipeline (or hand the package to your DevOps release pipeline if you run Azure DevOps). We configure your first close template with you, run one full close cycle in the sandbox against copied production data, and fix anything that surfaces. 5. Production. After your sign-off, the same package goes to production through your normal LCS deployment window. We provide the configuration steps, the security role assignments and a go-live runbook. 6. Support. A defined support window follows go-live for defect fixes and configuration questions, with a compatibility check when you take your next platform update.

Typical lead time from signed quote to sandbox delivery is two to four weeks, depending on the number of readiness checks and reconciliation types in scope.

What this is not

It is not a replacement for your general ledger, and it does not post entries on its own beyond the automated routines you explicitly authorise. It does not bypass F&O security: every action respects the caller's role, and close tasks are secured by dedicated duties and privileges we ship with the package.