LORENZ eValidator Alternatives: Compare Validation Scope and Reports

A team that needs a second validation profile has a different problem from a team that needs centrally managed batch runs. Neither necessarily needs a new publisher. The useful comparison starts with the submitted package, the checks applied to it and the evidence the team must retain after each run.

This guide compares those decisions through current product documentation and a proposed report-comparison record. Assyro publishes this article and appears first as our editorial preference. Sources were checked on September 14, 2026. We have not run competing validators or measured their accuracy; the exercises are evaluation designs, not reported product results.

Which alternative fits the validation job?

The shortlist includes a direct standalone candidate, a connected preparation workflow, an embedded publishing workflow and the incumbent edition-change option. They are different purchasing paths. Select only after the proposed configuration proves every mandatory requirement.

This is a scoped shortlist, not an exhaustive market ranking. Missing evidence makes a requirement unresolved; verified absence makes it unsupported. Neither outcome earns a pass because the product performs well elsewhere.

Identify the eValidator edition before requesting a replacement

LORENZ's current standalone product names are eValidator Basic, eValidator ONE and eValidator FIVE. These are not the similarly named docuBridge publishing editions. An inventory saying only “LORENZ FIVE” is too ambiguous for a replacement quote.

Basic has a particularly consequential restriction. LORENZ says the user selects a profile when first opening the software and cannot subsequently change it. Its broad description of available basic profiles should be read alongside that explicit selection rule. A free license is therefore not evidence that one installation can switch freely among all regional profiles. eValidator Basic product and download instructions.

ONE is positioned for a single user validating multiple regions or formats. LORENZ describes current and previous basic profiles, a one-year subscription and Windows workstation use. FIVE is positioned for multiple users and server operation, with basic and extended profiles, customization, browser-based task management and a batch-processing client. Confirm the actual licensed configuration rather than assuming every extension is included. eValidator ONE, eValidator FIVE.

Older material may call the server product “Enterprise.” Use the current product name and the installed release in your requirements document; a historical URL or manual title does not identify the capabilities you can buy today. Similarly, the number in a software release is not necessarily a validation-profile revision.

Source: LORENZ eValidator FIVE product page · View original image. The page displays this historical Enterprise 19.1 vendor example with an EU M1 3.0.2 / validation-criteria 6.1 profile. It illustrates result organization, not current rule coverage or a validation run performed for this comparison.

Ask the current administrator to collect one actual run record and its settings. Identify which checks come from an authority profile, which are vendor additions and which your organization configured. This inventory establishes what a replacement must reproduce and what the team may deliberately retire.

Assyro: evaluate earlier correction within a supported workflow

Start with Assyro when the objective is to connect document preparation, review and technical checking in a supported v4.0 workflow. The question is whether the people correcting the package can understand and resolve findings without repeatedly losing the source context. That is a more useful demonstration than a count of advertised checks.

Bring one permitted package and one recurring correction. Ask the operator to select the intended scope, run the applicable checks, locate the affected material and follow the correction through a new run. Require a clear distinction between findings resolved by changing the package, findings requiring human review and checks the system did not perform.

Inspect the record you can retain outside the active workspace. It should identify the tested package, tool and rule scope, run status and remaining findings. Treat those as demonstration requirements; this article does not certify that every requested report field or export format is available in Assyro today.

The version boundary is decisive. Assyro does not currently support eCTD v3.2.2. A team validating a continuing v3.2.2 application needs an eligible validator for that operation, even if it evaluates Assyro for another supported task. Do not turn an authoring improvement into a claim that the existing validation workflow has been replaced.

For an eligible v4.0 evaluation, confirm the authority, submission workflow and deployed criteria with the team demonstrating the product. The public validation offering establishes the starting point for that conversation; it does not establish compatibility with every eValidator profile, custom rule or historical report. Keep any retained publisher, validator and human review responsibilities in the proposed operating model.

EURSvalidator: compare licensed sets and report detail

EXTEDO EURSvalidator is the most direct standalone alternative in this shortlist. Its current product page describes eCTD and NeeS technical validation, regional subscriptions that can be combined, and simultaneous validation of pending submissions or dossiers. That makes the licensed set of requirements a central procurement question. EURSvalidator product scope.

Its product information also exposes a practical reporting distinction: the short PDF report contains detected errors, while the long report adds warnings and detailed information. A shorter report must not be mistaken for a run with fewer findings. The same document describes automatic validation-set selection but excludes NeeS from that automatic-selection behavior. EURSvalidator reporting and set selection.

For a Basic or ONE replacement, ask the vendor to demonstrate your required profile selection and both report views against the same package. Check that the person receiving the report knows whether warnings were included. For a FIVE replacement, add the real batch workload, custom-check requirements and report handoff; standalone validation alone does not prove equivalence to your configured server workflow.

Check the detailed support matrix as well as the marketing page. The document currently linked from the product page is titled EURS 8.0 and EURSvalidator 25.07 — Supported Validation Sets and Functionality. Its profile names, DTD references and licensing columns are separate pieces of information. Use it to request a current, release-specific mapping, not to infer that any number beginning with “4” means eCTD v4.0. EXTEDO supported sets and functionality.

For example, the inspected matrix includes an FDA-eCTD v4.4 profile row, while FDA's current criteria index identifies revision 4.6. A current website link to the matrix does not establish that it describes every update in the presently offered release. Request the matching current release documentation and a demonstration. Absence from the inspected matrix is an unresolved purchasing question, not proof that EXTEDO cannot support it.

DNXT Publisher: a different path when validation belongs inside publishing

DNXT Publisher documents a workflow from validation through correction, revalidation, approval and publishing. Its report uses Error, Warning and Passed labels and links findings to the affected TOC node or document. Those mechanics are relevant when the person resolving a finding is already working in Publisher. DNXT validation workflow, updated May 12, 2026.

Compare the actual issue-resolution path: open the finding, locate the affected material, make the correction and show its status in the next run. Ask how the original result remains retrievable and how the final report relates to the output handed to the next operator. Do not assume the displayed report and downloaded package are automatically the exact records your procedure requires.

The documented workflow also distinguishes errors from warnings and makes publishing with warnings dependent on organizational configuration. This is useful evidence about application behavior, not an equivalence between DNXT's labels and an authority's severity categories. Ask for the rule identifier and governing criterion behind a finding before translating it into a submission decision.

DNXT belongs on this shortlist as an integrated path, not a verified standalone drop-in validator. If your only objective is to validate packages from an unchanged publisher, require a demonstration of that precise input and output arrangement. If the proposed solution requires adopting Publisher or changing content handling, include that expansion in the scope and cost.

Other integrated products deserve the same treatment. Certara currently describes live validation in GlobalSubmit PUBLISH. Its older online help separately documents GlobalSubmit VALIDATE under release 22.9.1. That historical help does not establish a current standalone offer. Confirm the product and license being proposed before treating “GlobalSubmit validation” as equivalent to replacing eValidator alone.

Compare the standard, criteria and software release separately

A report labelled “FDA eCTD” still leaves several questions unanswered. Record the package standard, receiving center and application context; the regional profile and criteria revision; the validator release; and any enabled extended or custom checks. These values may change on different schedules.

The distinction is visible in FDA's current v3.2.2 materials. The standards index lists Specifications for eCTD Validation Criteria version 4.6, with support beginning August 28, 2026. The linked PDF's revision history dates version 4.6 to August 17, 2026. The index separately lists LORENZ eValidator 25.2 as the tool in use as of August 25, 2026. Those are different dates and version identifiers. FDA v3.2.2 standards and tools.

FDA's listing does not tell you that every LORENZ edition, purchased profile or local installation reproduces the agency's configuration. Nor does it establish a requirement to purchase a particular license. Compare the criteria applicable to your operation and obtain the configuration evidence for the actual candidate.

Likewise, LORENZ's current FIVE profile page lists US eCTD 3.2 and US eCTD 4.0 separately, alongside other authority/format profiles. That list helps identify the requested scope; it does not reveal the exact criteria revision installed on a particular workstation or server. eValidator FIVE profile list.

Before comparing two reports, reconcile their settings. If one uses additional checks, a different criteria revision or a different submission-history scope, a difference in finding count has several possible causes. It is not, by itself, evidence that either engine is more accurate.

Read severity and coverage before reading the green result

Preserve the report's original rule identifier, description, severity and location. Add your team's disposition separately. Relabelling every result “error” or “warning” in a spreadsheet can erase the distinction between an agency criterion and an internal publishing policy.

FDA's v3.2.2 criteria describe High severity as preventing processing and requiring resubmission; Medium needs further review to determine its impact; Low may or may not affect reviewability or integrity. These definitions concern receipt and reviewability, not scientific approval. The same specification notes that criteria 2–7 are not validated by the commercial off-the-shelf product. A tool pass therefore cannot establish that every agency check has been satisfied. FDA validation criteria v4.6, severity and scope.

Keep extended and organizational checks visible, too. They may be valuable for a company's operating standard without being identical to a published authority requirement. Decide who can approve a disposition, what supporting explanation is required and whether a correction requires another run.

An incomplete run, an unsupported input and an intentionally skipped check should not disappear into a green summary. Ask the vendor to show each condition separately. Technical conformance also leaves scientific interpretation and content approval with the appropriate reviewers; a plausible-looking document can still contain a substantive inconsistency.

Use this report-comparison record in the evaluation

The following is an original synthetic evaluation design. It contains no real submission, seeded package or vendor output. Use it to specify the records you want a vendor to produce with a legally usable sample and your approved acceptance criteria.

Start with a narrow assumed case: an operator needs standalone technical validation of an existing FDA v3.2.2 submission while retaining the current publisher. The required criteria are those applicable at evaluation time. A second operator must be able to retrieve the report and understand unresolved findings without the first operator present. Assyro is ineligible for that validation requirement because the format is unsupported.

Create an evaluation manifest identifying the source package and any required prior history. Record a file inventory and package identifier or hash, the installed software release, selected profiles and revisions, run date, operator, enabled extensions and report settings. Preserve each candidate's original report alongside the comparison record.

The table is a specification for the evaluation, not a promise that every candidate supplies every field. Do not insert a fabricated successful report where evidence is missing. Leave the item unresolved and ask for the actual output or a documented alternative that satisfies the same requirement.

To investigate a disagreement, first confirm that both runs used the same input, history and criteria. Then compare rule identifiers and check whether one report hid a category. Review the applicable source criterion before deciding whether the disagreement is a detection defect, a settings difference or an additional check. Escalate an unresolved interpretation; matching total counts is not an acceptance test.

Once the baseline is understood, repeat the correction and report-retrieval handoff with a backup operator. Record what remained manual and who owns it. A favorable result supports only the tested version, configuration and cases. It does not establish universal coverage, a false-positive rate or guaranteed agency acceptance.

What must survive a validator switch?

The valuable history is more than a folder of PDFs. Preserve the submitted or evaluated package, its run settings, original report, finding dispositions and the relationship between a corrected package and its subsequent run. Decide who can retrieve each record and what will happen when the old license or server is retired.

For a FIVE environment, inventory custom profiles and every system that reads a validation result. A new report can look clearer to a person while breaking an automated consumer that expects a particular field or status. Require a field mapping and a failure-handling demonstration. Historical report import and custom-rule translation remain unverified until the proposed tools demonstrate them.

Do not overwrite an old report with a new run under newer criteria. Retain the original evidence and label the later assessment separately. A changed result may reflect a changed package, changed settings or changed criteria; the record should let another operator tell which occurred.

Assign an owner to profile updates, an owner to report review and an owner to the retained archive. Specify how the team will learn about a criteria change, decide its applicability and confirm the installed configuration. These responsibilities remain even when a vendor supplies the update mechanism.

When staying or upgrading is the better choice

Stay with Basic when its selected profile fits the actual work and the team can retain adequate evidence. If a second region becomes necessary, first investigate ONE's broader profile arrangement. That is a concrete reason for changing edition; it is not proof that the incumbent's validation engine is deficient.

Retain FIVE while evaluating alternatives when batch operation, custom checks or downstream report consumers are critical. A candidate with an attractive report but unresolved rule translation is not ready to take over that operation. The strongest switch case is a demonstrated improvement with the required checks, records and handoffs preserved.

Add a complementary workflow when the recurring problem starts in source preparation or finding ownership. If the incumbent runs the required checks correctly, replacing it may leave that problem untouched. Evaluate Assyro for a supported workflow while keeping any required unsupported-format validation elsewhere.

Cost the options over the same period and workload. Include subscriptions or licenses, required profiles, setup, verification, training, custom-rule work, integrations, report retention and internal review effort. Count incumbent overlap once, and avoid treating retained archive access as an immediate saving. A free tool can be sufficient; a paid tool needs to justify its additional scope against the team's requirements. The eCTD software cost guide expands that comparison.

For a useful first conversation, bring the exact edition and release, one required profile, one original report and the handoff that causes difficulty. Discuss the supported validation workflow with Assyro when its scope fits. Ask for the evidence that makes the next decision possible: an eligible demonstrated operation, a retained responsibility or a clear exclusion.