How to Structure a UK SaaS Company for Enterprise Customers and Payment Providers

A growing UK SaaS company is, in effect, presenting itself for assessment twice, to two audiences applying different tests. The enterprise customer's procurement, legal and security teams are testing whether the vendor is a stable, low-risk counterparty capable of meeting contractual, security and data protection commitments over a multi-year term. The bank or payment provider is testing whether the company's revenue model, transaction patterns and documented business activity are consistent, low-risk from a financial crime and chargeback perspective, and unlikely to generate disputes, refunds or regulatory exposure that the provider would ultimately bear.

These two forms of scrutiny overlap in places, particularly around corporate transparency and the coherence of the company's public record, but they diverge sharply in emphasis. A procurement team cares intensely about data processing terms and sub-processor disclosure and is largely indifferent to the company's payment rails. A payment provider's underwriting team cares intensely about chargeback history and billing consistency and rarely asks to see a data processing addendum at all. A company that has invested heavily in one area while neglecting the other frequently discovers the gap only when it becomes commercially urgent.

This matters because the two audiences are engaged at different moments in a company's growth. Payment-provider underwriting typically happens early, often at the point the company first applies for a merchant account or payment gateway, and is revisited periodically as transaction volumes grow. Enterprise procurement scrutiny typically arrives later, once the company begins pursuing larger customers, and can arrive suddenly, with a single large prospective contract triggering a security review far more demanding than anything the company has previously faced.

The structural implication is that a SaaS company should not sequence its preparation reactively, building payment infrastructure to satisfy its first payment provider and then scrambling to build enterprise-grade contracting and data governance only once a large prospect demands it. The contracting entity, documentation suite and billing infrastructure described in this paper are best designed together, even if elements of enterprise-grade documentation are not required in full until the company's customer base justifies them.

The remainder of this paper addresses each dimension of that combined preparation in turn: entity and group design, enterprise procurement expectations, payment model selection, subscription billing discipline, banking and payment-provider underwriting, record-keeping, VAT treatment, and the practical steps to take when an application is declined.

The starting structural decision is which entity within the group actually contracts with customers, and whether that entity is the same one that applies for bank accounts and payment-provider relationships. For most early-stage UK SaaS companies, a single UK Ltd performs both roles, which is simple and generally appropriate while the company is small. As the group grows, particularly where a separate holding company is introduced above the trading entity for investor or tax planning reasons, it is essential that the contracting and payment relationships remain clearly attached to the correct entity, since confusion here is a recurring source of both procurement and banking friction.

A common structural error occurs where a holding company is introduced following a funding round, but customer contracts, invoicing and payment-provider accounts are left inconsistently split between the holding company and the trading subsidiary, sometimes because historic contracts were never formally novated to the new structure. Enterprise procurement teams reviewing such a company frequently ask, reasonably, which entity is actually liable under the contract, and an unclear answer stalls the review. Payment providers ask a similar question in different language, generally by requiring the merchant account holder to match the entity issuing invoices and receiving customer payments.

Where a group operates across multiple jurisdictions, for example a UK contracting entity alongside a US subsidiary handling North American sales, the structure needs to make clear which entity contracts with which customers, and intercompany arrangements should be documented to reflect that split. Enterprise buyers in each jurisdiction generally expect to contract with a locally recognisable entity, and inconsistency between the entity named in the contract, the entity issuing invoices and the entity operating the payment account is one of the most common causes of delay in both procurement and payment-provider review.

For companies still operating a single UK entity, the practical discipline is to ensure that the entity named in every customer contract, every invoice, the company's payment-provider merchant account and its bank account are identical, and that any change to that arrangement, such as introducing a new holding company, is accompanied by a deliberate decision about whether and how to novate existing contracts and payment relationships, rather than allowing drift to occur informally over time.

Group structure should also anticipate future enterprise requirements even while the company is small. Enterprise buyers increasingly ask, during procurement, whether the vendor has adequate financial standing and corporate governance to be relied upon over a multi-year contract term, and a coherent, properly documented group structure, even a simple one, answers that question more convincingly than a structure that has grown organically without clear ownership of the contracting relationship.

Selling to enterprise customers introduces a vendor onboarding process that is materially more demanding than the sign-up flow most SaaS companies design for smaller customers. Enterprise procurement teams typically request, at a minimum, evidence of the vendor's corporate standing, its data protection and information security practices, its financial stability, and its insurance coverage, before legal review of the contract itself even begins. A SaaS company unprepared for this sequence often finds procurement, rather than commercial negotiation, becomes the longest and most unpredictable stage of closing a large deal.

Security review has become a particularly demanding component of enterprise procurement, with buyers routinely requesting completion of a security questionnaire covering data encryption, access controls, incident response procedures, and sometimes evidence of independent certification such as ISO 27001 or a SOC 2 report. Smaller SaaS companies without formal certification are not automatically disqualified, but should expect to answer detailed questions about their security posture and should have accurate, honest answers prepared in advance rather than improvised during the review itself, since inconsistency between stated practice and actual practice is a common cause of procurement failure.

Financial stability checks, though less consistently applied than security review, are becoming more common for multi-year enterprise contracts, with some procurement teams requesting recent accounts or a financial reference before committing to a long-term subscription. A UK SaaS company with up-to-date, properly filed accounts at Companies House, and a coherent explanation of its funding position, is better placed to satisfy this check than one with overdue filings or an unexplained gap in its financial history, which reads as a genuine risk signal to a buyer's finance function.

Insurance is a frequently overlooked procurement requirement; many enterprise contracts specify minimum levels of professional indemnity and cyber liability insurance as a condition of signature, and a SaaS company that has not arranged appropriate cover before entering a large procurement process can find the requirement raised late, creating avoidable delay while cover is arranged and evidenced. Arranging appropriate insurance ahead of active enterprise sales activity, rather than reactively once a specific contract requires it, avoids this entirely foreseeable friction.

Taken together, enterprise procurement readiness is less about any single document and more about the company having a settled, accurate, and consistently presented account of its corporate structure, security practice, financial standing and insurance position, available before it is requested, since the speed of enterprise deal closure is frequently determined by how quickly and confidently the vendor can answer procurement's standard questions rather than by the underlying commercial terms.

The master services agreement is the commercial and legal foundation of an enterprise SaaS relationship, and a company selling into enterprise accounts should expect to negotiate its MSA rather than rely solely on a standard online terms of service designed for self-service customers. Enterprise buyers typically expect the MSA to address service levels, liability caps, termination rights, intellectual property ownership of any customisation, and audit rights, among other terms, and a vendor presenting only a generic terms-of-service document to a large prospective customer signals, correctly, that it has not yet built the commercial infrastructure enterprise buyers expect.

The data processing addendum sits alongside the MSA and addresses how the vendor processes personal data on the customer's behalf, a requirement that follows directly from UK GDPR and, where relevant, the EU GDPR, for any SaaS product that processes personal data belonging to the customer's own users or employees. A properly drafted DPA specifies the categories of data processed, the purposes of processing, data retention and deletion practices, and the security measures applied, and enterprise customers' data protection teams will generally decline to proceed without one in place, regardless of how strong the commercial terms otherwise are.

Sub-processor disclosure is a specific and increasingly scrutinised element of the DPA relationship: where a SaaS vendor relies on third-party infrastructure or service providers, such as cloud hosting providers, analytics tools or customer support platforms, that also process customer personal data, enterprise buyers generally expect a current, accurate list of those sub-processors, together with a mechanism for the vendor to notify the customer of any change. A vendor that cannot produce an accurate sub-processor list, or whose list does not match its actual infrastructure, creates a serious credibility problem during procurement precisely because it suggests the vendor does not have adequate oversight of its own data processing chain.

Maintaining this documentation is not a one-time exercise completed ahead of a single large deal; it requires an internal process for updating the sub-processor list whenever the company's infrastructure changes, and for reviewing the MSA and DPA periodically as the product, customer base and applicable law evolve. Companies that treat these documents as static, drafted once and never revisited, frequently find them out of step with actual practice by the time a sophisticated enterprise customer's legal team examines them closely.

It is worth noting explicitly that MSA and DPA drafting is legal work requiring a qualified solicitor familiar with SaaS commercial terms and UK data protection law; template documents obtained without proper review create a false sense of readiness and can expose the company to liability terms it has not genuinely assessed. The value an advisory practice adds in this area lies in coordinating the documentation suite and ensuring it is consistent with the company's actual operations, not in drafting the legal terms themselves.

SaaS companies accepting card payments generally choose between obtaining their own merchant account through an acquiring bank or acquirer, or contracting with a payment facilitator, sometimes described as a PayFac, that aggregates many merchants under its own master merchant agreement. The distinction matters structurally because it determines who bears direct underwriting responsibility, how quickly the company can begin accepting payments, and what degree of control the company has over its own payment relationship.

A dedicated merchant account, obtained directly with an acquiring bank or through a payment gateway that arranges one, generally involves a more thorough individual underwriting process, examining the company's business model, expected transaction volumes, chargeback history and financial standing, but results in the company holding its own distinct merchant identification and a payment relationship it controls directly, which can be more stable and more easily tailored to a growing enterprise SaaS business as it scales.

Payment facilitator models, by contrast, allow a company to begin accepting payments considerably faster, often within days, because the facilitator absorbs much of the individual underwriting burden by onboarding the merchant under its own umbrella agreement and monitoring risk on an aggregated basis. This speed comes with trade-offs: the company is subject to the facilitator's own risk tolerance and terms, can be suspended or offboarded more readily if its transaction pattern deviates from the facilitator's expectations, and generally has less negotiating leverage over pricing and settlement terms than a company with its own dedicated merchant account.

For an early-stage SaaS company with modest transaction volumes and a straightforward subscription model, a payment facilitator arrangement is frequently the pragmatic starting point, allowing the company to begin billing customers without the delay of full individual underwriting. As transaction volumes and customer concentration grow, particularly where the company begins processing higher-value enterprise contracts or expects sustained month-on-month growth, migrating to a dedicated merchant account, or at minimum understanding the threshold at which the facilitator's terms may no longer suit the business, becomes a more pressing structural question.

The right choice is not fixed and should be revisited as the business grows; a company that never revisits its initial payment facilitator arrangement can find itself constrained by terms designed for a much smaller merchant, while a company that pursues a dedicated merchant account prematurely, before it has the transaction history and financial standing to support the underwriting process, may simply face delay or decline without the benefit the more established route eventually offers.

Subscription billing introduces risk characteristics that payment providers assess specifically, distinct from one-off transaction businesses, because recurring charges generate a predictable pattern of customer disputes when billing is unclear, cancellation is difficult, or a customer forgets they hold an active subscription. A well-designed subscription billing system reduces this risk through clear pre-billing notifications, straightforward self-service cancellation, and prorated or clearly explained charges at renewal, upgrade or downgrade, each of which reduces the likelihood of a customer disputing a charge rather than contacting the company directly.

Chargebacks, meaning a customer's bank reversing a card payment following a dispute, are a metric payment providers monitor closely, and a subscription business with a chargeback rate exceeding the thresholds set by card networks risks being placed into a monitoring programme, facing additional fees, or ultimately losing its ability to process card payments altogether. The most common preventable cause of elevated chargeback rates in SaaS businesses is not fraud but confused billing: customers who do not recognise a charge, cannot find a way to cancel easily, or receive no notice before a renewal, and dispute the charge with their bank rather than contacting the vendor.

A clear, prominently available refund and cancellation policy reduces chargeback exposure by giving customers a straightforward alternative to disputing a charge; a customer who can request a refund easily and receive a timely response is considerably less likely to escalate to a chargeback than one who feels the only route to resolution is through their bank. Payment providers reviewing a SaaS company's application, or monitoring an existing account, generally expect to see this policy clearly published and consistently applied, not merely present in the terms of service as a formality.

Dunning management, meaning the process of handling failed recurring payments, such as an expired card or insufficient funds, is a further area that materially affects both revenue retention and payment-provider risk perception. A company with a well-designed dunning process, retrying failed payments appropriately, notifying customers clearly, and pausing rather than abruptly terminating service, presents as operationally mature; a company with no structured dunning process tends to accumulate failed payments, involuntary churn, and occasionally disputes from customers whose service was cancelled without clear warning.

Payment providers underwriting a subscription business will typically ask about expected chargeback rates, refund policy and average transaction value as part of the initial application, and will monitor actual performance against those stated expectations afterwards. A company whose actual chargeback and refund experience diverges significantly from what it described at underwriting should expect closer scrutiny, and in some cases account review or suspension, making it important that the figures provided at application are realistic rather than optimistic.

Banks and payment providers assessing a SaaS company for an account or an increased processing limit are, in substance, testing whether the company's stated business model, its actual transaction activity, and its documented corporate structure are all consistent with one another. A discrepancy between any of these, for example a company describing itself as a UK-focused business software provider while the majority of its transactions originate from unrelated jurisdictions with no documented customer relationship, is precisely the pattern that triggers enhanced review or a decline, regardless of whether the underlying activity is entirely legitimate.

For recurring revenue businesses specifically, underwriters generally look for a stable, explicable relationship between the number of active subscriptions, the average transaction value, and the total volume processed, and will treat sudden, unexplained spikes in volume, transaction values inconsistent with the stated pricing model, or a pattern of large numbers of small transactions inconsistent with a claimed enterprise customer base, as signals warranting further enquiry. A company that can readily explain its transaction pattern by reference to its actual customer contracts and pricing tiers moves through this review considerably faster than one whose billing data tells a different story to its stated business model.

Source of revenue and customer concentration are further factors underwriters commonly examine, particularly for a growing SaaS business transitioning from many small self-service customers to a smaller number of larger enterprise accounts. A sudden shift in transaction pattern following the closure of one or two large enterprise contracts is a legitimate business development, but should ideally be proactively explained to the bank or payment provider rather than left for the underwriting team to interpret unassisted from raw transaction data.

Ownership and management information also feeds into recurring revenue underwriting in the same way it feeds into any corporate banking relationship: an accurate PSC register, a settled group structure, and directors able to describe the business coherently during a KYC or ongoing review call all support a smoother underwriting process. Recurring revenue businesses are not exempt from the standard corporate transparency expectations that apply to any UK company seeking a banking or payment relationship, and gaps in that transparency compound the specific scrutiny recurring revenue models already attract.

The practical implication is that a SaaS company should treat its bank and payment provider not as a passive service but as an ongoing counterparty that periodically re-examines the business, and should be prepared to proactively explain material changes in transaction pattern, customer base or business model as they occur, rather than waiting for a review to be triggered and then responding defensively to questions that could have been anticipated.

Subscription revenue recognition is an area where SaaS companies frequently under-invest in systems relative to the complexity their billing model actually generates, particularly once the company offers annual as well as monthly billing, mid-term upgrades and downgrades, and usage-based components alongside a base subscription fee. Recognising revenue accurately over the period a service is actually delivered, rather than when cash is received, is both a UK accounting requirement under applicable financial reporting standards and a discipline that materially affects how the company's financial position is presented to investors, lenders and, indirectly, to banks assessing its accounts.

Beyond formal accounting treatment, the underlying record-keeping discipline that supports accurate revenue recognition, meaning a clear, contemporaneous link between each customer contract, each invoice raised and each payment received, is the same discipline that supports a coherent explanation to a bank or payment provider when transaction activity is questioned. A company that can trace any given payment in its bank statement back to a specific customer, contract and invoice within minutes presents a fundamentally stronger picture during any form of review than one relying on reconstruction after the fact.

This becomes particularly important where a SaaS company processes payments through more than one channel, for example card payments through a payment provider alongside direct bank transfer for larger enterprise contracts invoiced separately. Maintaining a single, reconciled view of all revenue across channels, rather than treating each payment channel as a separate, loosely connected record, is essential both for accurate financial reporting and for responding coherently when a bank or payment provider asks about the relationship between the company's stated revenue and its actual transaction activity.

Accurate record-keeping also directly supports VAT compliance, since HMRC expects a business to be able to demonstrate the basis on which VAT has or has not been charged on each transaction, particularly for a digital services business selling to customers in multiple jurisdictions where VAT treatment varies by customer location and status, addressed further below. A company whose billing system does not reliably capture customer location and business status at the point of sale creates a VAT compliance gap that is considerably more expensive to correct retrospectively than to design correctly from the outset.

The broader point, consistent with the governance discipline addressed in our companion publications, is that the systems a SaaS company builds to bill its customers accurately are the same systems that support its banking relationships, its investor reporting and its statutory tax compliance, and under-investing in billing and record-keeping infrastructure early creates compounding cost across all of these areas simultaneously, not merely in the one where the gap is first noticed.

SaaS products are generally treated as digital services for VAT purposes, and the correct VAT treatment of a sale depends principally on the location and status of the customer, meaning whether the customer is a business or a consumer and where they are established or resident. UK VAT law and, for sales into the EU, the destination-based VAT rules applicable to digital services each apply different treatment depending on these factors, and a SaaS company selling internationally should expect its VAT position to vary by customer rather than being uniform across its entire customer base.

For UK business customers, standard UK VAT rules generally apply, with VAT charged at the applicable rate where the selling company is VAT registered and required to charge it. For sales to VAT-registered business customers in other jurisdictions, reverse charge mechanisms may apply in some circumstances, shifting the VAT accounting obligation to the customer rather than the supplier, while sales to consumers in the EU are generally subject to the destination country's VAT rate rather than the supplier's home rate, a rule that has specific registration and reporting consequences for a UK supplier crossing relevant thresholds.

This is an area where general commentary, including this paper, should not be relied upon as a substitute for advice from a qualified UK VAT adviser or accountant familiar with digital services rules, since correct treatment depends on the company's specific customer base, jurisdictions sold into, and applicable registration thresholds, all of which change as the business grows and as VAT rules themselves are periodically updated by HMRC and by the relevant authorities in each market sold into.

What can be said generally is that a SaaS company's billing system needs to reliably capture the information required to apply VAT correctly at the point of sale, including customer location and, where relevant, a valid business VAT registration number, since retrospectively determining the correct VAT treatment for historic transactions where this information was not captured accurately at the time is a materially more difficult and costly exercise than building the capability into the billing system from the outset.

Founders should also be aware that VAT compliance failures, once identified, are a matter HMRC takes seriously, and a pattern of incorrect VAT treatment across a large volume of subscription transactions can represent a significant cumulative liability even where each individual transaction involved a modest amount. Engaging a qualified VAT adviser at the point international sales begin, rather than after a compliance gap has already accumulated, is consistently the more economical course.

The most common mistake among growing SaaS companies is building enterprise-grade contracting documentation only once a specific large deal demands it, while leaving payment infrastructure and billing discipline at an early-stage standard indefinitely, or the reverse: investing heavily in sophisticated billing infrastructure while neglecting the MSA, DPA and sub-processor disclosure enterprise buyers will eventually require. Both forms of imbalance create avoidable delay at precisely the moment the company can least afford it, during an active enterprise negotiation or a payment-provider review triggered by growth.

A genuine practical risk lies in treating the contracting entity and payment relationship as static once established. As a group restructures, introduces a holding company, or expands into new jurisdictions, the contracting entity named in customer agreements, the entity issuing invoices and the entity holding the merchant account can drift apart if the restructuring is not accompanied by a deliberate review of every customer-facing and payment-facing document, a gap that is often only discovered when a bank or a large customer's legal team asks a direct question the company cannot answer cleanly.

Commercially, founders should weigh the trade-off between payment facilitator convenience and dedicated merchant account control deliberately rather than by default, revisiting the decision as transaction volumes and customer concentration grow, since remaining on an early-stage payment arrangement well beyond the point it suits the business's actual scale is a common and avoidable source of friction as enterprise revenue grows.

Governance implications follow the same pattern addressed throughout our companion publications: a coherent, well-documented contracting and billing structure is, in substance, a governance discipline, evidencing that the board understands and has approved how the company contracts, bills and processes payments, rather than allowing these arrangements to evolve informally without board-level oversight as the company scales.

Banking implications deserve specific emphasis for SaaS companies, because the recurring nature of subscription revenue, the potential for rapid transaction volume growth following a successful enterprise deal, and the international nature of many SaaS customer bases are all factors that increase the scrutiny a bank or payment provider applies relative to a conventional, domestically focused trading business, making proactive, transparent communication with banking and payment relationships a genuine commercial asset rather than a mere compliance formality.

On long-term operational considerations, founders should plan for the structure described in this paper to evolve as the company grows from an early-stage, self-service billing model into a multi-entity, enterprise-focused group with a mix of card and direct invoicing, multiple currencies, and VAT registrations in several jurisdictions, and should build the underlying record-keeping and documentation discipline early enough that each stage of that evolution is a planned transition rather than a reactive scramble.

A declined payment-provider or bank account application is a common experience for SaaS companies, particularly early in their life or during periods of rapid growth, and it should be treated as a structured problem to diagnose rather than an outcome to immediately appeal or repeat elsewhere without analysis. Reapplying to multiple providers in quick succession without understanding the reason for a decline often compounds the problem, since repeated declines across several providers create a pattern that subsequent applications must overcome, in addition to whatever the original underlying issue was.

The first step following a decline is to seek, where the provider will offer it, a clear reason for the decision, recognising that providers are not always willing or able to give a detailed explanation, particularly where the decision relates to internal risk scoring. Where a reason is given, it should be addressed directly and substantively rather than superficially; a decline citing insufficient trading history, for example, is not resolved by reapplying immediately with the same limited history, but by building a longer operating record, stronger documentation, or applying to a provider whose risk appetite is better suited to an early-stage business.

Where no clear reason is given, a structured internal review is the appropriate next step, examining whether the company's PSC register, corporate structure and stated business activity are fully consistent with each other and with what was represented in the application, whether the company's website, terms of service and billing practices accurately reflect the business described in the application, and whether the founders and directors can coherently explain the business, its customer base and its transaction patterns if asked directly.

In our experience, declines are frequently the product of an inconsistency somewhere in this chain, a registered business activity that does not match the actual product, an outdated PSC register following an investment round, or a stated customer base that does not match the geography of the company's actual website traffic and billing data, rather than any inherent unsuitability of the business itself. Identifying and correcting the specific inconsistency, before making a further application, meaningfully improves the prospects of the next attempt.

Where a company has experienced multiple declines and cannot identify the underlying cause through internal review, engaging an adviser experienced in banking and payment-provider readiness to conduct a structured pre-application review, examining the company's documentation, structure and stated activity against what a provider's underwriting process is likely to test, is generally a more productive course than continuing to apply to successive providers without changing the underlying record those providers are assessing.