Untangling a Black-Box Integration to Finance Before Quarter-End Close

When an undocumented integration between your CRM and your finance system is blocking the quarter-end close, do the close first and the forensics second, and do not attempt both in the same week. First, produce a manually reconciled set of numbers from records the integration did not produce, signed off by finance. Then reverse-engineer the integration with no original author: identify the moving parts from the destination side, read the connection references and flow run history, capture payloads at the boundary and rebuild the field mapping from observed data. Meanwhile run a documented manual fallback with sign-off, and put a thin shim in place so the integration can be replaced in stages rather than through a big-bang cutover.

Why should you close the quarter before you fix the integration?

The close has a date and the integration does not. If the same people try to reconstruct an undocumented integration while finance waits for numbers, both jobs slip: the close is signed off on figures nobody can explain, and the investigation is rushed into changes made on the most sensitive days of the quarter. Worse, a fix deployed mid-close changes the behaviour of the thing that produced the numbers you are trying to reconcile, so you can no longer tell whether a difference came from the old logic or the new one.

Treat the close window as a change freeze for the integration. Nothing is redeployed, no batch is re-run to "catch up", and no mapping is edited. Re-running a batch of unknown design is how quarter ends acquire duplicate postings. The forensic work starts once the numbers are signed off, with a full quarter of evidence to work from rather than a moving target.

How do you produce reconciled numbers for the close without trusting the integration?

Reconcile against sources the integration did not write. On the CRM side that is the operational record: orders, invoices, credit notes, contracts or delivered work for the quarter, exported once, dated and kept read only. On the finance side it is what was actually posted, filtered to the entries the integration created. Match the two by the business key both sides share, usually the invoice, order or customer number, and sort every record into one of three buckets.

• Matched and equal: present on both sides with the same amount, tax, customer and period. These need no further work for the close.
• Matched with a difference: present on both sides but with a different amount, account, tax treatment, customer or posting date. Each one is investigated and corrected by finance with a documented adjustment.
• Present on one side only: created in the CRM and never posted, or posted with no source record behind it. These are the missing and duplicate postings, and they are the population that usually decides whether the close can be signed.

Keep the working file as evidence: the extract dates, the matching rule, every adjustment with who made it and who approved it. If the pattern of differences looks like wrong invoices rather than wrong postings, the method for sizing and containing that is in our guide to fixing the system behind billing errors. For anything touching audit opinion or disclosure, your auditors and your own finance leadership decide; this article is about the systems.

How do you find the moving parts when nobody knows how the integration works?

Start from the destination, because the finance system is the one place where the integration has definitely left a trace. Every posting it created carries evidence about how it got there, and that evidence leads back to the rest of the chain.

• The identity it posts as. Find the user, service account or application identity recorded against the integration postings. That name is the thread you pull next: where it is used, who owns it and what credential it depends on.
• The timing. Plot the creation times of the postings. A cluster at the same minute every night points at a scheduled job; postings seconds after a CRM record changes point at an event trigger such as a flow or plug-in.
• The entry route. Is it an import batch, a staging table, a file dropped in a folder, or an API call? The finance system import logs or staging tables usually show which, and your finance team or their vendor can read them.
• The sender. Search where the identity and schedule lead: Power Automate flows and Logic Apps with recurrence triggers, Azure Functions and Data Factory pipelines, SQL Agent jobs, Windows scheduled tasks, SSIS packages, and file shares or SFTP folders. In Microsoft Entra ID, sign-in logs for the service principal or service account show which application authenticated and from where.
• The CRM side. In Dynamics 365, list the plug-in steps, service endpoints and flows registered on the tables that hold orders and invoices. Our guide to taking over an undocumented Dynamics 365 environment sets out how to enumerate all of them.

Write each moving part down as you find it: component, where it runs, the identity it runs as, what triggers it, what it reads and writes. That list is the start of the documentation the integration never had.

What do connection references and flow run history tell you?

If any part of the chain is a Power Automate cloud flow, it is the richest evidence you have. The connection references in its solution show which connections it uses, and each connection shows the identity that authenticated it, which is often a person who has since left. Environment variables usually hold the things an author did not want to hard-code: endpoint addresses, company codes, ledger or journal identifiers. Read those before you read the flow logic, because they tell you which finance entity and which account structure the integration is aimed at.

Run history is the observed behaviour of the integration. Each run shows the trigger, every action that ran, and the inputs and outputs of each action, so a single run for a known invoice shows exactly what was read from the CRM and exactly what was sent to finance. Cloud flow run history is kept for 28 days, so for a quarter only the most recent weeks are still there. Export those runs on day one, even during the close freeze, because reading and exporting evidence changes nothing. Actions configured with secure inputs or outputs hide their values, which is a design choice and not a fault. For plug-ins, the plug-in trace log and System Jobs play the same role, as described in our emergency triage guide for integrations that silently lose records. How connection references and service accounts should be set up once you own the flow is covered on our Power Automate consulting page.

How do you capture payloads at the boundary without changing the integration?

Observe first, modify later. The aim is a set of real messages, each paired with the CRM record it came from and the finance posting it produced, captured without altering the behaviour you are trying to understand.

• Read what the platform already records: flow action inputs and outputs, Logic Apps run history, Application Insights if the author enabled it, and the finance system import log or staging rows.
• For file-based integrations, copy files from the drop or archive folder as they arrive, before the import job consumes or moves them.
• Where nothing records the payload, add capture in a sandbox copy first, then promote a logging step through your normal release path after the close, never as a hand edit in production during it.
• Store each payload with its business key, a timestamp and the run identifier, and only keep the personal or financial data your data protection rules allow.

A few dozen well-chosen pairs are worth more than thousands of random ones. Pick examples that cover each document type and each awkward case: a credit note, a multi-line invoice, a foreign currency order, a record created just before midnight on the last day of a period, a customer created in the same run as their first invoice.

How do you rebuild the field mapping from observed data?

For every field the integration writes into finance, find what in the source record explains it. Some fields are copied straight across, some are constants, and some are derived through a lookup or a calculation the author never wrote down. Record each one in a mapping table with five columns: destination field, source field or rule, transformation, the sample keys that prove it, and a confidence level.

The derivations that are usually hiding in a finance integration:

• Sign conventions, such as credit notes sent as negative amounts or as positive amounts with a document type.
• Tax, split per line or per document, and rounding applied at line level or at total level.
• Currency and the date the exchange rate is taken from.
• Date and time zone conversion, which moves records created late on the last day of a period into the next one.
• Ledger account, cost centre or dimension codes looked up from product, category, region or owner.
• The customer account number in finance, looked up from a field on the CRM account or matched by name.

Then test the reconstruction. Take a fresh sample of source records, apply your mapping by hand or in a spreadsheet, and compare the result with what was actually posted. Every record that does not reproduce exactly goes on an unexplained list, and nobody replaces the integration until that list is empty or each remaining item has a decision against it. Quarter end matters here: period cut-off, time zones, credit notes and closed periods rejecting late postings are the cases that only appear when the calendar forces them to, so make sure your sample includes them.

What does a documented manual fallback with sign-off look like?

While the integration is untrusted, finance needs a way to post the quarter that does not depend on it. A fallback is only a control if it is written down, owned and tested; an analyst who "fixes things up in a spreadsheet" is not one.

1. State when the fallback is invoked, for which document types, and who decides.
2. Define the extract: which CRM view or report, filtered how, taken at what time, saved where.
3. Define the reconciliation: extract against what the integration posted, using the three buckets above.
4. Define who enters or corrects postings in finance, with a second person checking each batch.
5. Name the finance owner who signs off each period, and record the sign-off with the extract and the adjustments.
6. Keep one register of every manual posting so nothing is posted twice when the integration resumes.
7. Rehearse it once before the next month end, not for the first time on the last day of the quarter.

How do you replace the integration without a big-bang cutover?

Put a thin shim at the boundary before you replace anything. The shim is a staging or outbox table where the CRM side writes one canonical message per business document, using the mapping you rebuilt and documented. The old integration keeps posting as it does today. The new path reads the shim and produces what it would post, but into a comparison area rather than into the ledger.

• Compare daily: what the new path would have posted against what the old integration actually posted, by business key and amount.
• Cut over one document type at a time, for example new customers first, then invoices, then credit notes, switching each only when its comparison has been clean.
• Give each document type a kill switch, so a problem returns that type to the old path or to the manual fallback without touching the others.
• Make every write idempotent on the business key, so a resend updates rather than duplicates.
• Keep the manual fallback available until a full month end, and preferably a full quarter end, has reconciled on the new path.

The outbox, retry, backoff and idempotency patterns behind that shim, and the honest test for whether you need middleware at all, are set out in our guide to rationalising point-to-point integrations. If the reconciliation showed records going missing rather than arriving wrong, contain that first using the silent record loss triage.

What does Solzet do, and what stays with your finance team?

Solzet works on the CRM side and the integration layer: Dynamics 365 Customer Engagement and Dataverse, Power Automate flows, plug-ins, service endpoints, the Azure components around them, the reconciliation and the shim. The same applies when the operational system is a custom-built CRM rather than Dynamics 365. We integrate with finance systems; we do not implement them. Solzet does not implement or reconfigure Dynamics 365 Finance, Business Central, Dynamics NAV, Finance and Operations, Supply Chain Management or any other ERP. Where the finance side needs a change, such as a new import key or a posting rule, we specify it and work alongside your finance team or their vendor.

If the black-box integration is one symptom of an estate whose partner or developer has gone, our Dynamics 365 project rescue and takeover service covers the first days, including recovering the identities integrations run as, and the rescue services guide covers freezing change and preserving evidence before anything is touched. The work is delivered remotely from Yerevan, Armenia by senior consultants and full-stack developers with 8+ years of Dynamics 365 and Power Platform delivery.

What should you do before the next close?

1. Freeze changes to the integration for the close window, including re-runs of failed batches.
2. Export flow run history and trace logs on day one, during the freeze, before they age out.
3. Export the CRM source records for the period and the postings the integration created, and reconcile them by business key into three buckets.
4. Have finance correct differences with documented, approved adjustments and sign off the numbers.
5. After sign-off, trace the integration from the destination side: identity, timing, entry route, sender, CRM triggers.
6. Rebuild the field mapping from observed pairs and test it on a fresh sample, including period-end edge cases.
7. Write, own and rehearse the manual fallback.
8. Build the shim, run the new path in comparison mode, and cut over one document type at a time.