Business Central speaks REST over OData, and from API v2.0 onward every record carries a GUID SystemId instead of the document number a partner's system recognises. That matters for one reason: the GUID tells you nothing about which price actually posted. If the invoice run pulls from the item card rather than the purchase order the partner sent, nothing in the API response flags it, it just surfaces weeks later as a deduction.
Most of what lands against this account comes down to a date, a quantity or a confirmation that Business Central recorded differently from the partner's own system. A delivery window missed by a few hours still reads as a miss on their side, regardless of what the sales order shows internally. An invoice line priced off the item card rather than the purchase order the partner sent shows up as a discrepancy on the remittance, not at the point the invoice posted.
Getting a partner trading on Business Central means agreeing the mechanics before a single purchase order arrives. The authentication model, the API version in use and the field that ties an invoice line back to the purchase order all need confirming up front, because none of them can be fixed retroactively once a batch has posted.
Each document reads from or posts to the same sales order record inside Business Central. The moment one of them reads from the item master instead, the chain still looks complete but the number at the end is wrong.
Posts out of the sales invoice record. If the line priced off the item card instead of the purchase order the partner sent, this is where the mismatch first becomes visible, usually after the fact.
Lands through the OData endpoint and gets a GUID SystemId on creation. The order number a partner recognises is not the key Business Central uses internally, which matters when a change comes in later.
Has to reference the same purchase order record the sales order was built from, not a derived number, or the partner's matching logic rejects it on arrival.
Built from whichever record last captured shipment, usually the posted sales shipment. Delay here almost always comes from a gap between posting and dispatch, not the message itself.
Has to update the sales order before invoicing runs against it, otherwise the 810 still posts against the original line.
A missing or late 997 reads as a dropped message on the partner's side even when Business Central processed the document correctly.
If any one of these six reads from the item master rather than the sales order it belongs to, the price downstream stops matching what the partner agreed.
Business Central runs REST with OData query support, and OAuth2 against Microsoft Entra ID is what a live account needs, since Basic Authentication is deprecated for anything running online. API v1.0 and v2.0 sit side by side, but v2.0 drops the nested properties for flattened, navigation-linked fields and keys everything off the GUID SystemId, while only v1.0 ships an OpenAPI specification. Extending past the standard endpoints means building a custom API from a copy, not extending an existing one.
Confirmed against your instance during onboarding.
Once Business Central is trading live with a partner, the account needs regular eyes on a short list of things rather than a one off setup. Each of these is where a quiet failure would otherwise sit until the remittance arrives.
997 and 855 responses are tracked against the partner's own clock, not Business Central's posting time, because a document processed on time internally can still arrive late.
Every 856 is checked against the shipment it was built from, so a dispatch recorded late in Business Central doesn't quietly become an ASN that reads as sent on time.
Each 810 line is compared against the purchase order it should have priced from, catching the case where posting pulled from the item card instead.
OAuth2 tokens, scope assignments and the API version in use get reviewed so a Microsoft side change doesn't surface first as a failed call during a live posting run.
Related
It depends on where the call lands. An OData query against the sales order and inventory records returns whatever is posted at that moment, but if the partner's own system caches that response before acting on it, the figure they're working from can already be stale by the time they place the order.
The 856 is built from the posted shipment record, so it can only go out once that posting happens. If shipment gets posted in a batch at the end of the day rather than at the point of dispatch, the ASN inherits that same delay.
Each page of results still comes back one OData call at a time, so a sharp rise in purchase order volume means more calls, not larger ones. The acknowledgement and invoice steps downstream of that pull are where the pressure actually shows, not the call itself.
Cogent² makes that change. Since custom API extension isn't available as a standalone option, altering what gets referenced means copying and building a new custom API rather than editing an existing endpoint, and that's work we do without it touching your team's time.
It can, provided the invoice posting routine runs straight after the shipment posts rather than waiting for a separate batch job. The gap worth watching is the time between those two postings, not the API call itself.
No. That setup is a one off configuration task and Cogent² handles it as part of bringing the account live, including keeping the registration and scopes current afterwards. It only becomes a hiring question if your team wants to own the connector itself.
Talk to a Cogent2 operator who has actually delivered this work. We will help you scope, plan and ship — without the agency overhead.
We use essential cookies to keep this site secure and working. We do not run advertising or analytics tracking. You can accept optional cookies or keep only the essentials. See our Cookie Policy.
