Alvys vs MercuryGate 2026: Freight TMS Buyer Guide

Start with your freight operation, including MercuryGate’s new name

Choose Alvys first for evaluation when your central problem is coordinating carrier, brokerage, or hybrid operations around dispatch and back-office work. Put MercuryGate first when your buying requirements center on complex transportation planning across modes, geographies, and business systems. These are starting recommendations based on public product scope; your actual freight and accounting workflows should determine the purchase.

MercuryGate’s TMS is now Infios Transportation Management, according to Infios. It remains an offered transportation product under a different brand. Ask for proposals, implementation responsibilities, and support commitments using the current product name rather than assuming an older MercuryGate comparison describes the present offering.

The ownership context also matters: the Infios rebrand was reported on March 17, 2025, with the business identified as a joint venture between Körber AG and KKR, according to DC Velocity. That establishes the corporate relationship; it does not establish what your particular subscription includes.

A transportation management system, or TMS, is software for planning, executing, tracking, and financially reconciling freight movements.

TL;DR: Evaluate Alvys around the daily load-to-invoice workflow. Evaluate Infios around transportation complexity and coordination across your wider supply chain. Neither should win because of a feature count, a funding announcement, or an unsupported claim about implementation speed.

Key Takeaways

• Alvys deserves close consideration when dispatch, driver activity, brokerage work, and accounting handoffs need to operate together.

• MercuryGate now means evaluating Infios Transportation Management; require a current scope document rather than relying on historical product descriptions.

• Treat both products as Quote-based for purchasing purposes because the reviewed public pricing material does not establish a usable subscription price.

• Integration availability and integration sufficiency are different questions. Confirm the exact fields, permissions, document access, and supported direction of data movement.

• Make missing mandatory capabilities a disqualifier before comparing weighted scores. An attractive interface cannot compensate for an unsupported customer requirement.

• Use native functionality before adding external automation, and require a named owner for exceptions, access changes, and ongoing maintenance.

Who this is for

This guide is for a freight broker, carrier owner, or hybrid operator choosing a core operating system. It is especially relevant when disconnected dispatch, tracking, document, and accounting processes are forcing staff to reconcile the same shipment repeatedly.

Your decision should reflect how you earn money. A carrier needs to connect freight commitments with equipment and driver execution. A broker needs to coordinate customer requirements, carrier selection, shipment progress, and financial reconciliation. A business doing both needs clear separation of responsibilities without losing the shipment’s commercial context.

Red flags: no internal owner for migration and acceptance; a mandatory integration that nobody has demonstrated with your data; an expectation that automation can make unreviewed carrier, payment, or customer commitments.

If your current TMS already handles the operational work, investigate the failed handoff before replacing the whole system. Missing document ownership or inconsistent customer references may require process repair rather than a different transportation platform.

How we evaluated the operating trade-offs

This is a public-information buyer’s guide, not a hands-on product test. The recommendations distinguish published product scope from our analysis of what that scope means for a buyer. Public information cannot establish your final price, migration effort, connector behavior, or negotiated support terms.

The weights below are our proposed purchasing framework, not research findings or vendor scores. They total 100%. The maximum-points column makes the weighting explicit; the rationale explains why each criterion deserves attention.

Apply mandatory requirements before scoring. If a product cannot support an essential shipper interface or approved accounting process, exclude it until the supplier demonstrates a supported solution. Do not average a disqualifier into a respectable overall score.

Then give both suppliers the same evidence packet: representative shipments, customer instructions, documents, charge adjustments, accounting mappings, and exception cases. Compare what an ordinary employee must do, which steps require configuration, and where another system becomes responsible.

A normalized feature matrix for the shortlist

The matrix describes published emphasis, not guaranteed inclusion in every contract. “Confirm” identifies an unresolved purchasing question; it does not mean the capability is absent. The acceptance column turns a broad feature claim into something your staff can inspect.

For dispatch, watch a reassignment rather than a clean initial entry. For financial controls, watch a disputed accessorial rather than a standard invoice. For integrations, inspect the receiving record rather than accepting a successful connection message.

These distinctions matter because feature labels hide operational differences. A tracking connection might provide location without the appointment context your service team needs. An accounting export might move invoice totals while leaving staff to reconcile customer references manually.

Alvys: evaluate the complete dispatch-to-accounting path

Alvys is the more natural starting point when the purchase revolves around running a carrier, brokerage, or combined operation. Its public presentation brings dispatch, load management, tracking, billing, and driver management together. The buyer question is whether those functions preserve the relationships and exceptions your business depends on.

Its corporate context is a venture-backed business rather than the MercuryGate-to-Infios combination. Series B funding: $40 million according to FreightWaves (2025). That report identifies cofounders Nick Darman and Leo Gorodinski and describes investment plans covering enterprise functionality, API integrations, analytics, and compliance. Funding is background for supplier diligence, not proof of feature availability or financial durability.

Alvys has also expanded its automation proposition: Foundry was introduced with more than 20 prebuilt agent templates, alongside custom and customer-assembled options, according to FreightWaves. Ask which capabilities are included in your proposal, what data they can access, and which actions require approval. Native agents do not establish equivalent access for external integrations.

Best fit: an operator whose purchase case centers on reducing repeated operational entry while retaining load, driver, carrier, and financial context. For a hybrid business, require a demonstration of entity selection, responsibility changes, and reconciliation when freight moves between your operating models.

Limitations to investigate: exact API field coverage, external write access, specialized transportation requirements, and configuration boundaries. A publicly advertised integration does not prove that its data is sufficient for your process.

Implementation approach: map your existing customer, carrier, driver, equipment, and financial records before migration. Establish which historical records need operational access and which can remain in an archive. Have dispatch and accounting accept the same representative shipment so that success in one department does not conceal extra work in another.

Infios: evaluate transportation complexity and module boundaries

Infios deserves priority when the difficult part is coordinating transportation decisions across modes, currencies, regions, or connected supply-chain systems. Its public scope emphasizes planning, optimization, execution, visibility, and broader suite connectivity.

Geographic coverage claim: 150+ countries according to Infios (2026). This is the supplier’s published scope claim, not evidence that your required lane, local document, language, or accounting treatment is configured. Require a demonstration of the specific regional workflow you intend to buy.

Best fit: a broker, logistics provider, or carrier with a documented need for transportation planning complexity that extends beyond straightforward dispatch. The deciding factor should be the requirements you can name, rather than an aspiration to own more software.

Limitations to investigate: module inclusion, implementation ownership, administration effort, and the distinction between transportation capabilities and adjacent products. Broad portfolio coverage does not mean every capability belongs to your proposed subscription.

Implementation approach: define system boundaries before discussing advanced optimization. Identify where orders originate, where shipment changes become authoritative, who approves rate exceptions, and where financial reconciliation occurs. Then establish the planning constraints and reference data that the system will use.

Do not assume a complex offering necessarily requires a slow implementation, or that a familiar brand guarantees an easy migration. Require a project plan tied to your data, integrations, operating rules, and acceptance responsibilities. Evaluate the proposed delivery team as carefully as the software.

Pricing and TCO: compare written scope, not advertised impressions

Pricing checked October 14, 2026.

Alvys is Quote-based: its pricing page describes monthly and annual options without publishing a usable subscription amount. Advertised integration access: 120+ integrations according to Alvys (2026). The page also advertises integration access without setup fees; confirm the contractual boundary between that statement and migration, custom development, third-party charges, or ongoing services.

Infios is Quote-based: its vendor-authored marketplace pricing section presents a 12-month contract structure and says all orders are custom, according to AWS Marketplace. It identifies modules and annual freight spend as pricing inputs. The displayed marketplace amount is explicitly a placeholder, so it should not be used as a purchase price.

Build a cost sheet that separates subscription obligations from implementation, internal labor, external systems, and ongoing maintenance. Ask how the quote changes when your operation adds a customer requirement, another business entity, or a new integration.

Also price the exit in effort. Determine how you would retrieve operational records, supporting documents, financial references, and configuration knowledge. An affordable subscription can still create an expensive dependency if essential information is difficult to extract.

There is no defensible cheaper-product winner from the reviewed public information. Compare equivalent written scopes and your own labor estimates before drawing that conclusion.

Integration diligence: what happens after the connection succeeds?

Treat integration as an operating responsibility. Your team needs to know how fresh the data is, which fields are missing, what happens after a failed request, and who can correct an exception. A connection without those answers can create another reconciliation queue.

A proposed workflow from US Tech Automations could begin when an authorized Alvys API read or scheduled export reveals a changed shipment status. It could match the shipment to accounting references and an approved document repository, then produce an internal billing-review packet identifying missing evidence. Prerequisites include vendor-approved access, stable record identifiers, available status fields, and permission to retrieve the documents. Accounting would review charges and supporting evidence before releasing an invoice; the design would not assume public API write access.

For an Infios environment, a proposed US Tech Automations workflow could trigger from an approved shipment export or a contracted interface that exposes an exception. It could compare the exception with customer instructions and create an internal task containing the source timestamp, responsible owner, and supporting records. Prerequisites include documented interface access, usable customer mappings, and an approved task destination. Dispatch would approve any carrier reassignment, while customer service would review any external communication. Without an authorized event interface, scheduled retrieval would be an explicit design limitation.

These workflows sit above the transportation system. They do not replace its shipment ledger, rate logic, or financial controls. Their purpose would be to organize cross-system evidence and handoffs while retaining clear human authority.

An illustrative exception-review calculation

Consider an illustrative broker reviewing 60 delivered loads: assume 45 have complete evidence and 15 require investigation. At an assumed 4 minutes per load, blanket manual review takes 60 × 4 = 240 minutes. If a proposed read-only process reduces review of each complete packet to 1 minute while exceptions still require 4 minutes, review becomes 45 × 1 + 15 × 4 = 105 minutes, a modeled reduction of 135 minutes, or 2.25 hours. These are scenario assumptions, not measured savings. For the authentication step, Alvys documents OAuth 2.0 and the required grant_type value client_credentials, according to Alvys. That documentation currently limits the public API to read operations despite listing write-related scopes, so this example ends with a human-reviewed packet rather than an automated TMS update.

The table exposes the same assumptions for replacement with your own observations.

Before using this model in a purchase case, measure document retrieval, false alerts, reviewer effort, and maintenance. Saved review minutes are not automatically reduced payroll costs, faster collection, or extra freight capacity.

Native tools, DIY automation, or an orchestration layer?

Start with native functionality when the work remains within the TMS. Adding another system to recreate an existing workflow introduces another access boundary and another owner. Ask each supplier to demonstrate its current configuration options before commissioning external work.

Zapier, Make, n8n, and an in-house integration can be reasonable alternatives for cross-system tasks. These approaches can support run histories, retries, error branches, and audit evidence when configured appropriately. Their suitability depends on available interfaces and the team operating them.

The buyer still needs to design and own observability, duplicate prevention, escalation, access controls, and maintenance. Retrying a failed read is different from safely repeating an action that might already have created a record. An apparently successful run also needs evidence that the intended business outcome occurred.

A proposed US Tech Automations design could configure shipment-based duplicate checks, freshness warnings, explicit exception ownership, and approval records across the participating systems. It would require authorized APIs or exports, documented matching rules, and an agreed maintenance owner. Your team would review ambiguous matches and sensitive actions. Those controls are design choices to evaluate, not capabilities unavailable to a competent DIY team.

When NOT to use US Tech Automations: use the existing TMS when its native workflow already handles the requirement; use a simple export and checklist when the handoff is occasional and easy to inspect; use an existing internal integration when your team already maintains the required controls. External orchestration needs a specific cross-system problem to justify its cost and ownership burden.

For adjacent examples of evaluation and workflow design, the membership-platform comparison, SaaS software buyer guide, and campaign exception recipe address other business contexts. Their transferable lesson is to define the operating decision and exception owner before choosing additional software; their sector-specific conclusions do not establish freight product fit.

Turn the shortlist into an acceptance decision

Review signal: 4.7/5 from 18 reviews according to G2 (2026). The reviewed page includes comments about API data completeness and interface complexity. Those are useful prompts for verification, not evidence that every account experiences the same limitation or that Alvys outranks Infios for your operation.

Use this decision checklist before committing:

• Operational fit: have dispatch and accounting process representative freight, including an amendment or dispute.

• Required coverage: demonstrate each essential mode, customer interface, entity boundary, and financial handoff.

• Data access: inspect actual fields, permissions, document retrieval, freshness, and failed-request behavior.

• Commercial scope: obtain an explicit list of included modules, services, integrations, and ongoing obligations.

• Cutover: assign migration ownership, reconciliation responsibilities, acceptance criteria, and a fallback procedure.

• Ongoing ownership: name the administrator and exception owner, and document how data can be extracted.

Choose Alvys when its demonstrated daily operating workflow fits your carrier or brokerage work and the required integrations expose sufficient data. Choose Infios when the demonstrated transportation-planning requirements justify its proposed scope and your team can own the configuration.

Pause either purchase if essential capability remains a verbal promise. An unresolved requirement belongs in the acceptance plan, not in an optimistic score.

Questions owners should settle before signing

Is MercuryGate still available?

The transportation product continues under the Infios Transportation Management name. Use current proposals and documentation to establish the contracting entity, product scope, implementation team, and support arrangements rather than treating the historical brand as a separate current purchase.

Is Alvys the better choice for a freight broker?

Alvys is a strong starting candidate when the broker’s priorities center on daily load operations and accounting handoffs. Require evidence for carrier onboarding, customer-specific documents, exceptions, and reconciliation. A brokerage with demanding multimodal planning requirements should evaluate Infios against the same acceptance packet.

Which product is cheaper?

Public information does not establish a reliable price winner. Both require a written quote for meaningful comparison. Normalize the included functionality, implementation work, integrations, support, and internal administration before comparing the commercial offers.

Can external automation update Alvys records?

Do not assume external write access from the existence of write-related scopes. The authentication documentation reviewed for this guide currently describes read-only public API operations. Obtain confirmation of a supported write mechanism before including automatic record changes in an implementation commitment.

Does an integration listing prove compatibility?

An integration listing establishes a reason to investigate, not proof that your workflow is supported. Inspect the required fields, document handling, supported direction, timing, and recovery behavior. Have the receiving team verify the resulting record rather than relying on a connection status.

Should we replace our TMS to fix missing-document follow-up?

Replace the TMS only if the underlying operating requirements also justify replacement. When shipment execution works and the failure is a document handoff, test native rules, a controlled checklist, or an authorized external workflow first. Measure the exception burden before expanding the project.

Make the purchase follow the demonstrated workflow

Alvys vs MercuryGate is ultimately a choice between operating requirements, with MercuryGate now evaluated as Infios. Begin with the work your team must execute, exclude unsupported mandatory requirements, and compare equivalent written scope.

Choose the product that demonstrates the necessary workflow with acceptable ownership and cost. If the remaining problem crosses system boundaries, see how US Tech Automations could configure the review handoff around authorized data access, explicit exception ownership, and human approval.