We’re experiencing issues with intercompany journal transfers through the REST API endpoint in our D365 F&O environment. The API calls started failing with duplicate document ID errors about two weeks ago, right after we updated our posting configuration for the new fiscal period.
The error occurs when posting intercompany journals:
POST /data/IntercompanyJournals
Response: 400 Bad Request
"Document ID IC-2025-0341 already exists"
The strange part is that these document IDs don’t appear in our existing journal records when we query the database. We’re using the standard REST API endpoint for intercompany journals, and the document ID logic seems unclear - we’re not explicitly setting these IDs in our payload, so they should be auto-generated. Has anyone encountered similar issues after updating posting configurations? Our integration was working perfectly for months before this started.
Have you verified the API endpoint version you’re calling? After 10.0.40, Microsoft changed how the IntercompanyJournals entity handles document ID generation when called via OData versus direct API. The endpoint might be trying to use a different number sequence than expected. Check if you’re hitting /data/IntercompanyJournals versus /api/data/v9.0/IntercompanyJournals - they can behave differently with auto-generated fields.
I’ve seen this before. The duplicate document ID error usually happens when the number sequence gets out of sync with the actual records. After posting config updates, the system sometimes doesn’t properly reset or advance the sequence counters. Check your number sequences for intercompany journals in the General Ledger parameters. Go to General Ledger > Ledger Setup > General Ledger Parameters > Number Sequences tab and verify the intercompany journal sequence. You might need to manually advance it past the conflicting range.
The issue might be with cached number sequence values in your API session. When posting configurations are updated, especially if they affect intercompany settings, the data entity framework can hold onto stale sequence allocations. Try adding a header to force a new session context: Prefer: odata.maxpagesize=1 and MSCRMCallerID with a fresh GUID. Also, are you batching these requests? Batch operations can sometimes reuse document IDs if the sequence isn’t properly locked between operations.
Thanks Sara. I checked the number sequences and they appear to be configured correctly with continuous allocation. The current number is IC-2025-0389, which is well past the failing ID IC-2025-0341. I also verified there’s no record with that ID in the LedgerJournalTable. Could this be related to how the API endpoint handles document ID generation versus the UI? We’re not passing DocumentId in our payload - should we be explicitly managing this field when using the REST API?
I suspect this is related to the posting configuration update you mentioned. When intercompany posting profiles or dimension settings change, D365 sometimes creates shadow records in staging tables that aren’t visible through normal queries but still block document IDs. Check the DMFDefinitionGroupExecution and DMFStagingLog tables for any pending or failed intercompany transactions around that ID range. These staging records can prevent the sequence from being reused even though the actual journal doesn’t exist.