Key takeaways
- Anvaigo EDI Connect handles EDI entirely inside Business Central — as an extension, without touching the standard.
- Fields are mapped through an assistant rather than written in code, which is why the vendor describes it as a no-code solution.
- Supported formats include EDIFACT, X12, VDA, IDOC, xCML, XML, CSV and XRechnung.
- Transport runs over AS2, FTP, SFTP, HTTP and API interfaces, so an external EDI service provider is not strictly required.
- The vendor is conion media GmbH in Germany, selling under the Anvaigo brand through partners.
Why EDI in mid-sized companies is usually somebody else's decision
EDI is rarely introduced voluntarily. Usually there is a customer behind it who only sends orders electronically and only accepts invoices electronically — and who dictates the format, not you. For a company with five such customers that means five format variants, five transport routes and five contacts who each expect something different.
Historically two routes follow from that. One goes through an external EDI service provider that translates the formats and hands you a uniform file — convenient, but with ongoing transaction costs and one more place where things can get stuck. The other goes through custom development in the ERP, which looks cheaper at first and becomes a burden at the next upgrade.
The third route is a standard extension that does the translation itself and stays inside the ERP. That is where Anvaigo EDI Connect sits.
What the extension actually does
Anvaigo EDI Connect is an extension for Microsoft Dynamics 365 Business Central and its predecessor Dynamics NAV. It reads incoming messages, maps their fields onto tables and fields in Business Central, creates documents from them — and the reverse for outbound.
The decisive point for maintainability is the nature of that mapping. It is configured through an assistant rather than programmed. Anyone who knows the format can maintain the mapping without writing AL; and because nothing in the standard object set is modified, the configurations survive the semi-annual release waves.
That is also the substance behind the claim that an EDI project can be delivered without customisation: not because EDI is trivial, but because the business logic sits in configuration rather than in code.
- Formats: EDIFACT, X12, VDA, IDOC, xCML, XML, text/CSV and XRechnung
- Transport: AS2, FTP, SFTP, HTTP and API interfaces
- Inbound and outbound messages in the same interface
- Runs with both the Essentials and Premium editions
- Available for Business Central and Dynamics NAV
Where EDI projects still go wrong
Technology is rarely the problem. The friction comes from master data and from agreements. An EDI document is validated automatically, and anything missing shows up immediately — unlike a PDF order, which a human will interpret if pushed.
Typical stumbling blocks are item numbers that the customer calls something else, units of measure in a coding nobody checked, and partner identifiers that work in test and not in production. Setting up the mapping tables early and working with real test messages shortens the implementation considerably.
The second underestimated point is operation afterwards. EDI runs until a customer changes their format. It pays to settle from the start who sees error messages, how quickly they are handled, and where the mappings are documented.
Frequently asked questions
- Not necessarily. Because the extension translates the formats itself and brings common transport routes such as AS2, SFTP and API, the exchange can run directly between you and the business partner. A provider still makes sense where a partner mandates a particular network or you deliberately want to outsource operation.
- That the connection is built through configuration and mappings rather than your own AL code in the standard. Effort still arises — analysing formats, mapping fields, testing — but it lands in a setup that is documented and upgrade-safe, rather than in development objects that have to be re-checked at every release wave.
- Yes, the vendor supports Business Central and Dynamics NAV. If you are already on a NAV version without active support, though, an EDI initiative is a good moment to look at both together: the move to Business Central and the EDI connection touch the same master data.
- That depends almost entirely on how clean the partner's specification is and how well your master data fits it. A partner with a clear specification and maintained item mappings is connected far faster than one whose format only becomes visible in testing. The first partner takes the longest; every further one benefits from the mappings already in place.