Eledone

Quotes, sales orders and delivery notes are written straight into the customer's ERP, an authenticated action in an outside system. "As soon as a purchase order or quotation is detected, it is automatically pre-filled in your ERP software." Creating a sales document in a company's system of record is a write with commercial consequence.

The homepage names twelve ERPs: Odoo, Divalto, NetSuite, Sage, Cegid, Sylob, Proginov, SAP, Infor M3, Exact Online, Oracle and Microsoft Dynamics 365. The ROI form offers SAP, Sage, Cegid, Microsoft Dynamics and an "Autre" option, which shows the list is a live commercial fact rather than a logo wall. The FAQ also documents a generic route: "Eledone IA has a universal interface which allows it to be connected to any ERP in a simple and secure way."

The reach is not bounded to one class of system. ERPs sit on the write side, and a mailbox and ticketing tools on the read side: asked whether a shared mailbox or a ticketing tool such as Freshdesk is compatible, the FAQ answers "absolutely, the Eledone AI model can be interfaced with an Outlook mailbox or any type of ticketing tool." A vertical focus on B2B sales administration does not narrow that.

No integration catalog page, connector documentation, supported version matrix or custom connector surface is published, and the universal interface is asserted rather than specified.

Sourceeledone-ai.com/en ERP compatibility section, eledone-ai.com/en/faq universal interface and mailbox questions, eledone-ai.com/en/produit ERP pre-fill stepread 2026-09-14

A genuine multi step flow runs from inbound email to a validated ERP document, performed by one model. The product page enumerates it: "find out how our AI model streamlines this process in three steps." A connected email interface classifies whether a message contains an order form or a quotation, a direct ERP connection prefills the detected document, and a validation screen lets a person confirm it.

The second step subdivides into customer resolution against the client table and per line product resolution against the catalog, and delivery notes add a conditional branch: "reconciliation with existing purchase orders where applicable." That is a pipeline with a data dependent path, not a single call.

One model performs the whole sequence: no agents are named, no roles are distinguished and no handoff between actors is described. There is no BPMN, named runtime, workflow graph, versioning, authoring surface or customer configurable branching; the one conditional is fixed by the vendor.

The scope is also narrow. Nothing downstream of the validated document is orchestrated: no confirmation to the customer, no exception queue for unmatched lines and no retry or failure path, so what happens when a product line cannot be resolved is unpublished.

Sourceeledone-ai.com/en/produit three-step process, eledone-ai.com/en delivery notes reconciliation, eledone-ai.com/en/devis per-line matchingread 2026-09-14

Output is grounded in the customer's own master data through entity resolution, but no maintained retrieval structure is documented. The homepage sets it apart from extraction: "much more than a simple OCR, Eledone IA interfaces with your databases to make exact matches with your customer and product internal entities." The quotes page names both lookups.

Customer recognition uses the email address and the information in the customer's document to "find the right reference in your customer database". Product recognition works line by line: "for each product line, Eledone uses the information supplied by the customer (descriptions, dimensions, references, etc.) to create a match in your product database." Resolving a free text order line to a specific SKU is grounded generation: the output is constrained by the buyer's data rather than the model's priors.

The model's domain training ("during long months of R&D in France's top artificial intelligence laboratories, our model was specifically trained and optimized for quotation and sales order processing") lives in its weights, which are not a retrieval structure over the customer's knowledge.

Matching runs directly against the ERP's customer and product tables at run time, and no index, graph or embeddings layer that Eledone builds and maintains is described. The ERP tables are the application's data model, not a knowledge layer the vendor persists. There is also no citation or provenance surface showing which catalog row a line resolved to or with what confidence, which on a product whose failure mode is a wrong SKU is the gap a buyer would feel first.

Sourceeledone-ai.com/en/devis customer and product recognition steps, eledone-ai.com/en OCR distinctionread 2026-09-14

A mandatory review gate is stated as a product property: "The Eledone artificial intelligence model never works in total autonomy. Human validation is always required to validate data entry." Nothing reaches the ERP as a committed document until a person accepts it; the agent produces a prefilled entry, not a posted one. An always on gate with no autonomous path around it is stronger than a configurable one, not weaker.

The gate is Eledone's own. The quotes page says "all the sales assistant has to do is validate the new quote in his ERP", which on its own could read as dropping a draft into the customer's system for approval in that system's interface.

The product page settles it: "our review screen is integrated into your ERP so you can be efficient and validate the order quickly, without having to do any typing." The review screen is shipped by Eledone and embedded in the ERP, which supplies the frame but not the gate. What a person reviews is the document the model produced, line by line, before it becomes real.

The screen's mechanics are undocumented: no approval roles, record of who validated or rejection path appears anywhere, and there is no documentation site to carry them.

Sourceeledone-ai.com/en/produit validation step, eledone-ai.com/en/faq autonomy answer, eledone-ai.com/en/devis validation stepread 2026-09-14

No security assertion about the product that a buyer could evaluate is published, and no attestation either. Privacy boilerplate, generic encryption language and appeals to industry standards say nothing specific, since every company with a website says them.

Everything Eledone publishes falls on that side of the line. The data privacy page offers GDPR adherence, "Eledone works according to the rules described by the General Data Protection Regulation" and "our model is hosted in the European Union and complies with the standards in force", which is a legal obligation every company processing European personal data already owes and distinguishes this vendor from nobody.

The rest is a generic set repeated across the homepage, the privacy page and the FAQ: "independent environments", "strict access controls", "encryption" and "secure protocols". Strict access controls names no access model: no SSO, SAML, SCIM, RBAC or other role based permissions. Per customer isolation is multi tenancy architecture rather than a control a customer operates.

No attestation exists anywhere: no SOC 2, ISO 27001 or trust center. The absence is well evidenced: the dedicated data privacy page, the FAQ's own security answer ("Is there any danger in implementing an artificial intelligence model in my company?") and the product pages all say the same, and there is no documentation site or admin material where an access model could be.

Sourceeledone-ai.com/en/confidentialite, eledone-ai.com/en/faq security answer, eledone-ai.com/en Confidence section, navigation enumerated across six pagesread 2026-09-14

What the agent did leaves no documented record. No audit trail, processing log, history of handled messages, per document record of what was extracted or which catalog entry a line resolved to, confidence score, error or exception report, dashboard or volume reporting appears anywhere on the site. A customer application exists at app.eledone-ai.com behind a login and presumably holds a console of some kind, but nothing published says what it shows.

The one adjacent feature is a live signal, not auditing. The product page offers "a smart, connected e-mail interface": "in your inbox, we tell you whether an e-mail contains an order form or a quotation." That shows what the agent thinks about the message in front of the user at the moment of use; it does not let anyone reconstruct what happened or why.

The gap is sharper because every document passes a mandatory validation gate, so a person accepts or corrects each one, and nothing published records who validated what, when, or what they changed. A vendor whose FAQ argues it reduces disputes and entry errors has reason to keep that evidence and may do so inside the application, but it is not claimed. An ERP's own document history would not fill the gap either, since that is the customer's system supplying its own logs.

Sourceeledone-ai.com/en/produit, eledone-ai.com/en/faq, eledone-ai.com/en/confidentialiteread 2026-09-14

Nothing the agent writes and reads back is documented, at any scope: no stated lifetime or purge path, no memory object per user or workflow, and no description of the agent carrying anything from one processed document to the next. No store of facts a user maintains for the agent to consult is documented either.

What the product persists is the customer's own commercial records, quotes, orders and delivery notes, and those live in the ERP as the customer's system of record. Deleting them would delete the business record, which is what separates a data model from a memory layer. The ERP's customer and product tables are the same: a database many things read and write is not a memory layer, however central it is.

Entity matching can look like memory, since the agent resolves a free text line to the same SKU every time, but the catalog is the customer's data queried at run time. Recognizing a repeat customer from an email address is a lookup, not retained state. The model's training for quotation and sales order processing is general domain competence held in weights, not state.

A correction learning loop, with corrections made on the validation screen persisting per customer, would be natural for this product, but nothing published claims one.

Sourceeledone-ai.com/en/produit, eledone-ai.com/en/devis, eledone-ai.com/en/faqread 2026-09-14

Delivery is SaaS hosted in one region, the European Union, with no choice offered. The data privacy page states "our artificial intelligence model is hosted in the European Union and complies with the standards in force", and the FAQ repeats it for the customer's own space: "your space is independent and hosted within the European Union." Disclosure is not a choice: a buyer with a different requirement could not get a different answer. A French vendor selling to French and European manufacturers has little reason to offer one, and nothing suggests it does.

Each customer gets an independent, isolated environment, but that is how the vendor separates customers inside its own estate, not a buyer choosing where the software runs. Eledone makes no softer residency claim either: no regional options, no hosting aligned to a buyer's jurisdiction, nothing offered on request. No region list, VPC, on premises option or selection surface is published, and GDPR adherence is a legal obligation, not residency.

Sourceeledone-ai.com/en/confidentialite hosting statement, eledone-ai.com/en/faq environment answerread 2026-09-14

One agent handles several document types, and no prebuilt agents, templates or packs are published. The homepage shows three named cards, Sales orders, Quote and Delivery notes, each with its own heading, description and "Read more" link, which could look like a set of separately adoptable products.

All three links resolve to the same product page, and that page treats them as document types in one flow: "Don't waste any more time manually entering your sales documents (quotes, orders, delivery notes, etc.), find out how our AI model streamlines this process in three steps." The "etc." makes it open ended coverage of a single capability, not an enumerable set of assets.

Removing delivery notes would remove no product; the same flow would simply handle fewer document types. The job is identical in all three cases: detect a sales document in a mailbox, resolve its entities against the ERP, prefill it and present it for validation.

Nothing adoptable is published by any other route: no catalog, template library, gallery, bundled toolkit, module or entitlement language, per unit pricing, enable or install action, or per product page with its own URL. The ROI form prices one motion, orders per month, with no unit selection. The twelve named ERP connectors are integrations, not prebuilt agents. A focused single purpose agent simply has nothing to package.

Sourceeledone-ai.com/en/produit sales documents phrasing, eledone-ai.com/en three product cards resolving to one pageread 2026-09-14

Work reaches Eledone through an inbound queue: a message arrives and the agent fires, with no person invoking it. The product page describes "a smart, connected e-mail interface" ("in your inbox, we tell you whether an e-mail contains an order form or a quotation"), and the quotes page says "as soon as a quote request is detected, the artificial intelligence model generates a new quote in your ERP."

The ingress spans two system classes, not email alone. Asked whether a shared mailbox or a ticketing tool such as Freshdesk is compatible, the FAQ answers "absolutely, the Eledone AI model can be interfaced with an Outlook mailbox or any type of ticketing tool." A named mailbox platform plus an open class of ticketing systems is real inbound breadth for a product whose whole input is customer correspondence.

Both inbound routes are one mechanism: a message lands and is classified. No schedule, webhook or programmatic trigger is documented, so no other system can start the agent directly. On this product that is a real boundary. An order arriving through EDI, a portal or a phone call never reaches Eledone, and the ROI form's question about existing EDI use shows the vendor knows those paths exist.

Sourceeledone-ai.com/en/faq mailbox and ticketing answer, eledone-ai.com/en/produit inbox detection step, eledone-ai.com/en/devis detection triggerread 2026-09-14

A proprietary model trained for order processing does the work, and the customer cannot select or route models. No model selector, routing disclosure or bring your own key path appears on the site. The product is sold as one model doing one job, in the singular throughout: "Adopt Eledone, the first artificial intelligence model for automating your sales administration" and "the Eledone artificial intelligence model connects to your mailbox."

Eledone states that it trained the model itself: "during long months of R&D in France's top artificial intelligence laboratories, our model was specifically trained and optimized for quotation and sales order processing". The homepage sets it apart from commodity extraction as "much more than a simple OCR." A purpose trained model is a defensible product choice, and it is also the most complete form of no choice.

No underlying provider, model family, architecture or version is named, and no subprocessor list exists on the site, so a buyer sending customer purchase orders and pricing cannot learn what processes them. Naming its own model is real disclosure, and still no choice at all.

Sourceeledone-ai.com/en Efficiency section and product cards, eledone-ai.com/en/devis model descriptionread 2026-09-14

Eledone documents plug and play ERP connectors but no public API, SDK or MCP for building on Eledone itself. Every documented interface points outward. The FAQ's "universal interface which allows it to be connected to any ERP in a simple and secure way" is Eledone reaching into another company's system, and the same holds for the mailbox and ticketing connections. A bridge that exposes the customer's systems to the agent does not expose the vendor's platform, so nothing lets an outside caller drive Eledone.

No REST API, SDK in any language, MCP server, A2A agent card, outbound webhook, CLI, marketplace listing or embeddable component is documented. There is no developer portal to be gated either, so this is not restricted access but nothing to access.

The site is small and fully enumerable, and it has no developers or documentation entry, API reference or docs subdomain. The only subdomain, app.eledone-ai.com, is a customer login rather than a developer surface. Eledone makes no API claim at all, which fits a product sold to sales administration buyers rather than developers.

The twelve named ERP connectors are integrations and say nothing about whether this platform is callable. A vendor integrating with twelve ERPs necessarily has internal interfaces, and a partner or integrator program could exist unpublished behind the demo booking, but nothing is published.

Sourceeledone-ai.com/en/faq universal interface answer, eledone-ai.com/en navigation and footer read across six pagesread 2026-09-14

There is no documented way to evaluate a change to the agent: no evaluation harness, no scored test cases, no quality gate in a release path and no optimization loop after deployment. Nothing lets a buyer run the model against a known set of purchase orders and read how it did, compare two versions, or sample its output systematically. No processing log is published to read after something goes wrong either.

The vendor makes accuracy claims without published measurement: "today, we enable our customers to significantly reduce the number of disputes and errors generated by sales teams", and a named customer reports "a gain in serenity" and "reducing the number of input errors in our ERP." An outcome claim is marketing and a testimonial is a reference, not an evaluation surface. No error rate, match accuracy or benchmark is stated.

The validation gate is not evaluation. Every document passes a human review screen before it commits, but that gates each individual output rather than testing a change. The ROI calculator is a presale lead form that estimates savings from a buyer's own volumes and measures nothing about the agent.

A match confidence or exception view could sit in the authenticated application at app.eledone-ai.com, but nothing published claims one.

Sourceeledone-ai.com/en/faq error answer, eledone-ai.com/en testimonials, eledone-ai.com/en/pricing ROI formread 2026-09-14

Mailbox and ERP integrations do the work, with no browser or computer use. Nothing on the site documents a hosted or local browser, a desktop session, or remote or local computer control driven by the agent. The mailbox is read through an integration with Outlook or a ticketing tool, and the ERP is written through what the vendor calls a universal interface. Both are programmatic connections to systems that expose them, the opposite of operating an interface where no programmatic route exists.

Two features could be mistaken for computer use. The inbox surface ("in your inbox, we tell you whether an e-mail contains an order form or a quotation") may well be an add-in that labels messages, but a panel annotating what a person is already looking at is display, not an agent driving a screen. The review screen "integrated into your ERP" is a vendor component the customer's staff operate; the agent does not click through it.

The ERP write is not interface operation either. Prefilling a sales order in SAP or Sage happens through a connection the ERP exposes, not by typing into its forms, and the vendor sells the absence of typing as the benefit: "validate the order quickly, without having to do any typing."

No UI is targeted, so a changed screen has nothing to break, and approval of submissions is handled by the validation gate rather than an interface permission. Reading PDFs and scanned handwritten orders, which the ROI form lists among the formats handled, is document extraction, not computer use.

Sourceeledone-ai.com/en/produit inbox and validation steps, eledone-ai.com/en/faq mailbox interfacing answerread 2026-09-14