Montreal-based Valsoft reported its completed acquisition of Square 9 Softworks, of New Haven, Connecticut, through wholly owned TAG Software Group on September 8, 2026. The announcement leaves the price and exact legal closing day undisclosed. The release describes channel-partner delivery across several business sectors.
Square 9 presents software that captures information from documents, turns it into usable records and shares it across systems. Its applications include accounts payable, employee onboarding, order processing and contracts. That connects the document itself to work someone needs to complete: finding information, moving it to another person or putting it into a business application. These are the company’s descriptions of its offering.
How Square 9 developed
Square 9’s company history distinguishes a 2005 incubation project from incorporation in 2006. Its starting ambition was to make enterprise content management accessible to smaller businesses. That history explains the company through the handling of business information: how a business finds, moves and uses it. The original problem was the work surrounding paper and the difficulty of giving smaller organizations tools associated with larger enterprises.
The company dates its Solutions Delivery Network to 2020: a cloud-hosted library of predesigned applications. It identifies a separate cloud capture development, GlobalCapture Cloud Transformation Services, in 2021. Those milestones describe two different parts of the product’s development—packaging applications for delivery and developing cloud capture. This is the company’s own account of its history; it does not establish what each customer used or when a particular implementation changed.
The ownership model TAG describes
TAG presents itself as a Valsoft operating group built around long-term ownership and decentralized local leadership. Its proposition combines continued brand and leadership identity with shared support in areas including acquisitions, AI, finance and talent. That is a different organizational question from whether a particular product feature works: who runs the operating business, and which functions can draw on a wider group?
For an owner reading that model, the useful distinction is between local operating leadership and shared functions. A decentralized model can still include group resources; the presence of group functions does not itself describe every decision right. TAG’s public description is a statement of how it intends to operate. It is not a transaction contract, a guarantee of permanent ownership or evidence that a particular business has received measurable benefits.
The Square 9 announcement’s leadership-continuity language fits that stated proposition. Neither account demonstrates subsequent product improvements or customer results from this acquisition.
From captured document to payable record
Square 9’s accounts-payable offering describes capturing documents, extracting information for financial systems, routing items for approval, coding transactions and creating payable records. Each function has a different job. Extraction supplies information; coding classifies the transaction; approval determines whether it can move forward. The description establishes an offered workflow, rather than proving that every customer has removed manual work or that a payable has been paid.
For an owner, the connection is useful: a document can be available and searchable before the related transaction is ready to proceed. Capturing information and moving it through an approval process are connected parts of the offering. Asking only whether software can read an invoice leaves the rest of that work unexplained.
The company’s business-process automation page describes a workflow builder for mapping processes, routing exceptions, escalating approvals and sending reminders. Those functions bring the path through the business into the product explanation. An exception needs somewhere to go; an approval may need another person; a reminder addresses an item that has not moved. A no-code builder describes how the vendor offers process design. It does not establish that an implementation needs no technical work, that its rules are correct or that every exception disappears. A process map therefore needs to describe handoffs and exceptions, rather than just the successful route through it.
Connections have specific jobs
The integrations directory describes connectors with different scopes, alongside document-data exchange with business applications. Its FAQ also describes confidence flags for fields needing review. That is useful context for a buying discussion, but a connector’s name alone does not specify every supported action or establish a customer’s configuration.
The PDI integration description makes the distinction concrete. The vendor describes trade invoices passing through a merchandising module and into PDI. It describes non-trade invoices taking an approval route based on location, department, amount or other criteria. Once approved, those invoices are coded and exported to PDI Enterprise. These are specific paths within the advertised offering; they should not be flattened into a claim that every invoice follows one automatic route. The consequential detail is the sequence: for the described non-trade path, approval comes before coding and export. The advertised destination does not, by itself, explain how an item gets there.
What the Dutch Group account adds
An undated customer account published by Square 9 describes Dutch Group’s paper invoices being hand-delivered, signed and moved in envelopes, with retrieval problems when documents went missing. The implementation began with clinics, followed by pharmacies. It included capture, indexing, archiving, approval routing and information exchange with PDI.
The account describes multiple approvers, store-limited visibility and director-wide access. It also describes PDI check-number feedback updating an invoice, while people still search, review, approve and send information. A check number is not proof of bank settlement. This vendor-published account does not establish measured savings, the current configuration or a change caused by the acquisition. The example connects physical invoice handling, who can see the record and what the financial system sends back.
The customer account illustrates one implementation; the PDI product description cannot establish which specific routes that customer actually configured.
The acquisition becomes clearer through that work: a document-software business offers capture alongside configurable routes to approvers and other applications. The route matters as much as the presence of captured information.
For general information and education, not legal, tax, investment or valuation advice. Reported transactions do not predict your business’s value, financing terms or sale outcome. Consult qualified advisers about your situation.
Subscribe to Deal Flow Canada for practical owner guides and Canadian deal updates.