Quick answer: Require stable transaction identifiers, replay-safe processing, durable error handling, and reconciliation from the source system through to the ERP. A timeout is not proof that a transaction failed, and acceptance by a connector is not proof of posting. Before retrying an uncertain transaction, establish what the destination actually recorded. Microsoft’s messaging guidance explicitly distinguishes successful-but-unacknowledged operations from genuine failures. (learn.microsoft.com)
For controllers, finance leaders, and ERP administrators, the useful question is not simply, “Does this connector support our ERP?” It is, “Can we account for every transaction when something goes wrong?”
Use the following requirements when evaluating or implementing payroll, banking, procurement, or CRM integrations. They are a control-design checklist, not a claim that every ERP or connector provides these capabilities automatically.
1. Define ownership and mapping before connecting systems
Create an integration contract for each transaction flow. Record:
- Business owner: who decides whether the transaction is financially correct.
- Source owner: who corrects upstream records and confirms export completeness.
- Technical owner: who investigates delivery failures and authorizes replay.
- Authoritative system: which application controls each field.
- Completion point: whether success means delivery, import, approval, posting, or another explicitly defined state.
Do not give two applications unrestricted authority to overwrite the same financial fields. Instead, document the permitted direction of each update and how corrections enter the process.
Build a mapping specification that covers more than matching column names:
| Mapping area | Practical requirement |
|---|---|
| Company | Explicit source-to-ERP legal-entity mapping |
| Accounts and dimensions | Approved lookup values; reject unmapped combinations |
| Amounts | Defined signs, precision, rounding, and currency |
| Dates | Separate transaction, accounting, and extraction dates |
| Parties | Stable customer, supplier, employee, or bank-account references |
| Document lines | Persistent line identifiers and header relationships |
| Corrections | Rules for updates, cancellations, reversals, and replacements |
These are recommended design checks. For Dynamics 365 Finance specifically, Microsoft documents that account structures determine valid account-and-dimension combinations and whether dimension values are required; mappings should respect the destination’s configured rules.
Require an explicit decision for blank, unknown, inactive, and newly introduced values. Avoid a catch-all account or company unless finance has approved that treatment.
Practical check: Ask the implementation team to show what happens to a transaction containing an unknown cost center—not just one with perfectly mapped data.
2. Separate transaction identity from delivery attempts
Use distinct identifiers for distinct purposes:
- Business transaction ID: identifies the source document or event.
- Operation key: identifies the intended action, such as creating a particular payroll journal.
- Attempt ID: identifies one transmission attempt.
- ERP record ID: identifies the destination record once established.
A synthetic operation key might be:
PAYROLL|COMPANY-A|RUN-0042|CREATE-JOURNAL
Keep that key unchanged when retrying the same action. A legitimate reversal or replacement needs its own defined identity, linked to the original.
Idempotent processing means repeating the same operation has no additional effect. Require durable tracking, protection against concurrent attempts, and a defined response when the same key arrives with conflicting data. A simple “check whether it exists, then create it” sequence has a race condition if two workers perform the check together. (learn.microsoft.com)
Verify the actual API behavior. NetSuite REST, for example, documents an upsert operation using PUT and an external ID in the request URL. Upsert creates or updates a record; it is not the same as rejecting a replay. Establish whether repeating a request could modify an existing record before using it for financial recovery. (docs.oracle.com)
Also separate queue protection from ERP protection. Azure Service Bus duplicate detection filters repeated message identifiers within a configured window; that does not establish that a financial record was created only once. (learn.microsoft.com)
Common mistake: Generating a fresh operation key for every retry, making the replay look like a new transaction.
3. Track business completion, not just API responses
Design the integration register to show meaningful states, for example:
Captured → Validated → Submitted → Imported → Posted → Reconciled
Add exception states such as Rejected, Outcome unknown, and Awaiting approval. Adapt these labels to the actual workflow; not every interface exposes every state.
For asynchronous imports, retain the execution or job identifier and monitor the job after submission. Dynamics 365’s Data management package API provides GetExecutionSummaryStatus, including states such as Executing, Succeeded, PartiallySucceeded, and Failed. Its GetExecutionErrors operation retrieves job error messages. (learn.microsoft.com)
Require connector demonstrations to answer:
- Does the displayed success status mean submission or completed import?
- Can an accepted batch contain rejected records?
- Where are record-level errors available?
- What evidence confirms the expected ERP document exists?
- Is posting a separate step?
Keep import completion and posting confirmation separate in the control design unless the verified interface explicitly combines them.
Record the ERP product, deployment, API, connector version, and relevant configuration alongside the design. Do not copy a rate-limit number from another endpoint or an older implementation.
For example, Microsoft’s current Finance and Operations documentation distinguishes resource-based protection from historical user-based limits and describes their version-dependent applicability. Treat the documented environment and endpoint—not a generic requests-per-minute assumption—as the starting point. (learn.microsoft.com)
4. Make retries bounded and error queues recoverable
Use a recovery decision table rather than retrying every failure identically:
| Condition | Recommended response |
|---|---|
| Invalid account, dimension, or required field | Quarantine for correction |
| Authentication or permission failure | Escalate to the access owner |
| Throttling | Follow the documented delay and reduce pressure |
| Network timeout | Establish the destination outcome before unsafe replay |
| Conflicting data under an existing key | Stop for investigation |
| Retry budget exhausted | Move to a monitored exception process |
For Dynamics 365 Finance and Operations service-protection responses, Microsoft documents HTTP 429 and a Retry-After interval. Continued demanding requests can extend the waiting interval. Respect that signal instead of immediately resubmitting the backlog. (learn.microsoft.com)
Set an explicit retry budget and escalation deadline appropriate to the finance process. Where the interface permits it, use increasing delays with random variation to avoid synchronized retry bursts.
An error or dead-letter queue should preserve the source reference, operation key, attempt history, error details, and correction owner. Restrict access to sensitive payloads.
A queue is not an operating procedure. Azure Service Bus dead-letter queues, for example, do not clean themselves up automatically; messages remain until explicitly retrieved and completed. Assign responsibility for review and recovery. (learn.microsoft.com)
Practical check: Demonstrate recovery of one failed item without resubmitting successful items from the same batch.
5. Trace one payroll journal through success, timeout, and replay
The following is a synthetic control example, not a vendor-specific journal payload or accounting recommendation.
Assume an approved payroll export should create one USD journal:
| Illustrative line | Debit | Credit |
|---|---|---|
| Payroll expense | $12,000 | — |
| Payroll clearing | — | $12,000 |
| Total | $12,000 | $12,000 |
Use the operation key PAYROLL|COMPANY-A|RUN-0042|CREATE-JOURNAL.
Normal success
Validate the mapping and balanced totals, submit through the tested interface, and retain the returned job or ERP record ID. Confirm import and posting separately where required. Finally, match the journal back to the approved source export.
Timeout after submission
Suppose the ERP creates the journal but the response never reaches the connector. Such successful-but-unacknowledged operations are a documented failure scenario. Mark the result Outcome unknown, not definitively failed. (learn.microsoft.com)
Before another create attempt, use the destination’s supported lookup or job-status mechanism. Confirm identity and relevant business fields. If the outcome cannot be established safely, hold the item for investigation.
Replay after a worker restart
The worker receives the same operation again. A durable completed record should direct it to the previously established result. An unfinished processing record requires reconciliation rather than an assumption that nothing happened. (learn.microsoft.com)
If the journal exists but has not posted, recover the appropriate posting step under the normal approval controls. Do not create another journal merely because posting is incomplete.
The recovery checkpoint should document which transaction exists, its status, and which exact action is safe next.
6. Reconcile identifiers and totals across the whole flow
Use reconciliation as an independent control, not merely a summary of connector success messages.
For each agreed company, currency, transaction type, and cutoff, compare:
- Eligible source transactions.
- Transactions captured by the integration.
- ERP records created or imported.
- Posted records, where posting is required.
- Unresolved and deliberately excluded items.
Match transaction identifiers as well as counts and amounts.
For a synthetic example, suppose the source contains three documents:
- A: $100
- B: $100
- C: $200
The expected count is three and the expected total is $400. If the destination contains A twice and C once, both checks still pass. Identifier-level comparison exposes the missing B and duplicate A.
For payroll journals, retain the approved debit and credit totals separately; a balanced journal’s net value alone is not a useful completeness check.
For monitoring, require a view of unconfirmed submissions, unresolved exceptions, oldest pending items, and reconciliation differences. Set alert thresholds around the relevant business deadline rather than choosing an arbitrary universal target.
Also require an explanation for no activity: an empty source, a failed extraction, and a stopped integration should not look identical to the operator.
7. Prove failure recovery in a sandbox before go-live
Make the failure cases part of acceptance testing:
- Submit the same operation twice, including concurrent submissions.
- Interrupt the response after the destination commits.
- Restart the worker during processing.
- Replay an older item after the queue’s duplicate-detection window.
- Send conflicting data under the same operation key.
- Reject one item within a multi-item batch.
- Trigger throttling and verify the documented waiting behavior.
- Test an unknown dimension, expired credential, and closed posting period.
- Stop the source export and confirm the absence is detected.
Queue duplicate detection is time-bounded, so test late replay explicitly rather than assuming earlier duplicate tests cover it. (learn.microsoft.com)
For every case, capture source identity, operation key, attempt history, destination evidence, financial status, and reconciliation outcome. Use nonproduction data and approved sandbox access.
Before cutover, agree who can pause delivery, authorize replay, approve corrections, and sign off reconciliation. The supplied Microsoft go-live checklist calls for completed integration and acceptance testing, verification steps, monitoring arrangements, and operational support readiness.
Finally, distinguish stopping an integration from undoing its financial effects. The recovery plan should identify how to suspend new submissions, preserve unresolved work, and route existing ERP records through the approved correction process.
Acceptance standard: For every eligible transaction, the team should be able to show its identity, current state, destination evidence, and next safe action. If the connector cannot expose that information, require a compensating control before relying on it.