Deltek and Stedi integration

What moves between them

Outbound, ml-connector reads finished AR invoices from Deltek Vantagepoint and sends them to Stedi as X12 810 invoices for delivery to each client trading partner, and can send purchase orders to vendors as outbound 850s. Inbound, Stedi parses purchase orders and acknowledgments from trading partners and pushes them by webhook, and ml-connector posts them into Deltek as projects and accounting transactions. Deltek firms and GL accounts are aligned with the matching trading-partner identifiers and transaction settings so each document maps to a valid Stedi partnership. Outbound runs on a poll tied to your billing calendar, while inbound is event-driven from Stedi.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the Deltek client ID, secret, username, and password used for the OAuth2 password grant against the tenant URL, and the Stedi API key. It refreshes the Deltek bearer token when a call returns 401, and presents the Stedi API key in the Authorization header on every request. Because Vantagepoint has no usable event stream for finance data, ml-connector polls Deltek for new and updated AR invoices on a schedule rather than waiting for a push, and translates each into the JSON shape Stedi expects before calling generate-edi. Inbound 850 purchase orders arrive through the transaction.processed.v2 webhook; ml-connector returns 2xx inside the five-second window, then fetches the full payload from the documentDownloadUrl with the API key and writes it into Deltek asynchronously. Every outbound EDI call carries a Stedi Idempotency-Key, and inbound events are deduplicated on the Stedi eventId, so neither a retry nor a duplicate webhook posts twice. Firms and GL accounts are mapped first so every document references a partnership and transaction setting that already exists. Deltek has no native idempotency, so ml-connector checks for an existing record by invoice or PO number before posting. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized architecture and engineering firm of about three hundred people runs Deltek Vantagepoint for project accounting and client billing, and a few of its largest institutional clients require invoices over X12 EDI rather than PDF. Before the integration, a billing clerk exported each EDI client's approved invoices from Deltek and hand-keyed them into a separate EDI portal, then watched for purchase orders to arrive by email and re-entered them as projects. With Deltek and Stedi connected, approved AR invoices flow out as 810s automatically and inbound 850 purchase orders post straight back into Deltek as projects, so the EDI clients are billed on time and the manual portal step is gone.

What you can do

• •Send approved Deltek Vantagepoint AR invoices to Stedi as outbound X12 810 invoices for delivery to client trading partners.
• •Post purchase orders that Stedi parses from inbound EDI into Deltek as projects and accounting transactions.
• •Bridge the Deltek tenant OAuth2 password grant and the Stedi API key, refreshing the Deltek token on expiry.
• •Map Deltek firms and GL accounts to Stedi partnerships and transaction settings so each document routes correctly.
• •Poll Deltek on your billing schedule and accept Stedi webhooks, with idempotency on both sides and a full audit trail on every record.

Questions

Which direction does data move between Deltek and Stedi?

It moves both ways. AR invoices created in Deltek go out to Stedi as X12 810 documents for client trading partners, and purchase orders that Stedi parses from inbound EDI come back into Deltek as projects and accounting transactions. Stedi holds no business records of its own, so Deltek remains the system of record on both halves of the flow.

Does Deltek support webhooks, or does ml-connector poll it?

Vantagepoint only has workflow-driven callbacks with no signature and no general event stream for finance data, so ml-connector polls Deltek for new and changed AR invoices on a schedule you set. Stedi is the opposite: inbound purchase orders are delivered exclusively by webhook through the transaction.processed.v2 event, with no polling alternative. The connector handles each side in its native style.

How does the integration avoid duplicate invoices and purchase orders?

Every outbound EDI call to Stedi carries an Idempotency-Key, which is valid for 24 hours and returns the cached result on retry instead of generating a second file. Inbound webhook events are deduplicated on the Stedi eventId, and because Deltek has no native idempotency, ml-connector checks for an existing record by invoice or PO number before posting. Any failed step is logged and can be replayed.