Government SaaS procurement now has a catalog door.

A SaaS company that wants Japanese public-sector customers should now decide whether its product belongs in the Digital Marketplace, or DMP, and whether the organization is ready for what comes after listing.

DMP gives packaged cloud software a catalog route into national and local government procurement. It changes discovery and selection: an administrative buyer can search across functions, security information, and price, identify products matching a requirement, and use that result in a procurement process.

It does not turn a listing into a sale. It does not make the Digital Agency the buyer for every transaction. It does not replace security requirements or buyer-specific contracting.

The practical decision is therefore not “should we upload our product?” It is “can we operate a repeatable public-sector sales and delivery model around a catalog entry?”

What DMP changes

The Digital Agency released the production DMP catalog on October 31, 2024. Its procurement operation for national administrative bodies and local governments began in March 2025.

The Digital Agency overview describes the problem DMP is intended to address. Traditional government IT procurement often starts from a system built to specification and uses a process that can be lengthy and burdensome. DMP instead catalogs software already available in the market and related implementation services. Buyers can search and compare information needed for procurement rather than begin every market scan from zero.

That creates a door for vendors that might have been difficult for a public buyer to discover. It is particularly relevant to smaller companies and startups because a common catalog can reduce the need to establish visibility separately with every organization.

The door is procedural, not preferential. A buyer still needs a valid need, budget, procurement method, and contract. The product still competes on its fit with the buyer's specification.

DMP can support discretionary contracting or nominated competitive bidding after a buyer searches against its requirements. The procurement route depends on the result and the applicable rules. A catalog search is part of the evidence for selection; it is not a waiver of public-procurement discipline.

Confirm that the offer is in scope

DMP is for licensed, packaged cloud software and related services needed to introduce and operate that software. The Digital Agency's procurement manual describes the software as SaaS, in effect an existing product.

The same manual excludes an offer containing hardware and SaaS that requires development by the vendor. This boundary is important for companies that use “SaaS” to describe a wider project. Configuration, setup, data migration, help desk, user support, and other related services may fit the catalog model. A bespoke application-development engagement does not become DMP-eligible merely because the finished application will be hosted in the cloud.

A vendor should separate the reusable product from project work. Define the standard license, standard configurations, supported integrations, implementation choices, service levels, and priced optional services. If a buyer's core requirement can only be met through new development, the DMP route may not be the right procurement vehicle for that requirement.

This boundary is also useful product strategy. A company that repeatedly customizes the product for each customer may need to standardize its offer before it can benefit from catalog procurement.

Listing begins with supplier eligibility

The fiscal 2026 application notice sets out participation requirements. A supplier normally needs the All-Ministries Unified Qualification in both sale of goods and provision of services, at grade A, B, C, or D. A manufacturer that does not sell directly has a stated qualification exception. The supplier also needs an appropriate G Biz ID account and must accept the participation rules and framework contract.

The framework contract is with the Digital Agency and is renewed by fiscal year. It sets common conditions for using DMP and registering products. A company cannot publish a catalog entry first and resolve supplier status later.

The current guidebook describes a sequence: obtain the unified qualification and G Biz ID, sign the DMP basic contract, register company information, register software or select software as a seller, and register related services. The DMP office checks submitted information before publication. The guidebook gives indicative review periods of about eight business days for software and about two business days for services.

Those are review indications, not a promise of end-to-end market readiness. Time is also needed to prepare evidence, resolve questions, correct registration data, align a reseller relationship, and meet the annual contract cycle.

A foreign SaaS company should make an early route-to-market decision: register through a qualified Japanese selling entity, use a qualified reseller, or build the local capability needed to contract itself. The catalog supports both software companies and sales companies, but ownership of product information, pricing, customer support, security answers, and contract performance must be clear.

The transaction remains buyer-to-seller

After publication, an administrative buyer searches for software and services that match its requirement. It can contact the listed seller, run the applicable selection process, and enter an individual contract.

The Digital Agency's basic contract creates the catalog framework. It does not mean that the Digital Agency buys every listed service or guarantees payment for another organization. The individual administrative body and the seller establish the transaction.

That means the vendor still needs public-sector commercial operations. It must answer buyer questions, prepare quotations, support the selected procurement method, negotiate the individual contract within applicable rules, onboard the organization, invoice correctly, and maintain service and security evidence.

A catalog entry without an owner for inquiries and contracting can reduce credibility. The listing should be connected to a sales queue with response times, escalation, and a clear handoff to implementation.

Security information is visible, not waived

DMP allows buyers to compare security information, including whether a cloud service is registered under ISMAP or ISMAP-LIU. This is helpful because it places security attributes next to functional and commercial information.

It does not make DMP registration a security certification. Government cloud-selection guidance can require or favor ISMAP or ISMAP-LIU depending on the information and system involved. A buyer may impose additional requirements for data location, access control, incident reporting, subcontractors, continuity, or sector-specific operation.

A vendor should therefore treat the catalog's security fields as an index into a larger evidence set. Keep current security architecture, certifications, audit reports, data-flow descriptions, privacy documentation, subprocessor information, incident procedures, and service-continuity material ready for buyer diligence.

The legal and program-scope caution is short but important: DMP is a procurement catalog and selection mechanism. It does not replace the Public Accounting Act, local procurement rules, security policy, privacy law, or the authority of the purchasing body to determine its requirements.

The counterargument

The strongest counterargument to calling DMP a new market door is that listing can create administrative work without creating demand.

Public buyers may adopt DMP at different speeds. A product can be visible but still fail a required feature, security condition, budget limit, integration need, or contracting term. An incumbent vendor may have stronger references and deployment capacity. A small supplier may obtain catalog access yet struggle with long sales cycles or the documentation needed by an administrative customer.

This counterargument is valid. DMP should not be evaluated by listing completion alone.

The relevant commercial metrics are qualified inquiries, procurements in which the product passes the search criteria, win rate, contracting time, implementation cost, renewal, and the amount of buyer-specific work. If those signals remain weak, the vendor should reconsider its segment, product packaging, partner model, or the priority assigned to government sales.

The catalog is most valuable when the product already solves a recognizable public need in a standard form. It is less valuable when every opportunity requires a new product, an unsupported deployment environment, or one-off contractual architecture.

What remains unknown

The official materials do not establish uniform adoption by every ministry, agency, or municipality. Each organization has its own needs, timing, and procurement governance. A vendor cannot infer market size from the existence of the catalog.

Buyer-specific security requirements remain unknown until the intended data and use case are understood. An ISMAP status shown in search can be decisive in one procurement and insufficient or unnecessary in another.

Demand quality is also unknown at registration. Catalog users can compare a product, but the public materials do not promise a minimum number of inquiries, a standard sales cycle, or a contract value.

The boundary between configuration and development can require judgment. A standard integration or migration service may be catalog-compatible, while extensive new functionality is not. The vendor should confirm ambiguous packaging with DMP guidance rather than make the catalog description broader than the actual standard product.

Finally, annual rules, basic contracts, registration fields, and operating guidance can change. Product and company information must be maintained rather than treated as a one-time application.

A practical operator decision

Start with product fit. Write a one-page definition of the packaged SaaS, licensed features, standard configuration, supported deployment model, and related services. Mark any hardware or custom development as outside the DMP offer.

Next, choose the contracting entity. Confirm the unified qualification categories and grades, G Biz ID, Japanese contracting capability, invoicing, support, and whether a reseller will sell the software. Put product-information and security-update responsibilities into the partner arrangement.

Then build the catalog evidence. Use specific functions, deployment constraints, price logic, implementation requirements, security status, and support terms. A buyer should be able to understand what is standard and what requires a separate discussion.

Connect the listing to an operating funnel. Assign owners for buyer inquiries, quotations, procurement documents, security diligence, legal review, implementation, and reference capture. Track why opportunities pass or fail the buyer's search and selection process.

Finally, revisit the offer after actual inquiries. Repeated requests for the same integration or migration service may justify standardizing it as a listed service. Repeated failure on a security requirement may justify a certification or architecture investment. Repeated demand for custom development suggests that the current product is not yet aligned with the DMP route.

The operator decision is to enter DMP when the company has an eligible packaged SaaS offer, a qualified contracting route, current security evidence, and staff to convert catalog discovery into individual contracts. Listing before those pieces are connected creates presence, but not market access in the operational sense.

Source limitation

This analysis relies on Digital Agency primary materials available through August 11, 2026: the DMP overview updated July 8, 2026, the fiscal 2026 application notice dated February 2, the DMP guidebook dated April 28, and the July 2025 procurement manual. These sources describe intended operation and eligibility, but do not provide uniform adoption or conversion data for every public buyer. Digital Agency content is generally covered by its Public Data License 1.0 policy, with attribution, modification disclosure, and stated exclusions.