Let's talk about cashflow. Or in GovCon speak, let’s talk about Contract Financing. Many small businesses assume that they will get paid during the performance of their government contract, but that is not always the case. Unless specifically provided for in your contract, the government default is to pay contractors once all items have been delivered and/or all services have been performed.
For many smaller companies, this type of arrangement is not an option, particularly for labor-based or longer-term contracts. Enter contract financing. How important is contract financing? So important that it has an entire FAR part dedicated to it. Note that contract financing is a specific term that applies to certain payment types eligible for use only on fixed-price contracts. For cost-type or other contracts not within the fixed-price family (such as Time and Materials or Labor Hour), contractors are typically paid before the end of the contract. However, this is a different payment process and is not considered contract financing, which I will not cover in this post.
Another common payment type that has become more frequent is milestone payments, often used on SBIR/STTR contracts. These are payments that align with contract events or deliverables that have commensurate values and scheduled payout dates based on the individual contractor’s proposed work plan. If a contractor is selected, the government may approve this plan and pay the company accordingly, or give the awardee the option to switch to partial payments, where the total award value is divided by the total number of months in the scheduled period of performance and paid at the end of each month.
Separately from milestone payments, two of the most commonly used contract financing types are Progress Payments and Performance-Based Payments.
Progress Payments can either be based on percentage of work completed/stage of completion, which is commonly used in construction acquisitions, or based on costs, which requires additional surveillance of the contractor’s accounting system to validate progress payment compliance.
Performance-Based Payments are very similar to milestone payments in that they tie to specific events and are set at an amount commensurate with the value of the event. They typically have an associated deliverable used to validate successful completion of the event and are tied to significant points along the critical path, spaced to protect the USG’s interest while also providing steady cash flow to performing contractors.
All contract financing types have additional rules around payment rates, supervision, approval, and administration that are unique to the payment type. For more information on contract financing or to learn about other types of payments, check out FAR Part 32.
Now, let’s talk about contract financing payments for software acquisitions.
For many dual-use software companies, the payment schedule is incredibly important and can tie to company revenue goals and bookings. Depending on the contract, you may see the same license paid on a monthly basis or for one year up front, shortly after the contract is awarded. So what gives?
Oftentimes this confusion stems from how the government buys software and whether they categorized the contract as a product acquisition or a service acquisition.
The SaaS model has been around for quite awhile, but government acquisition regulations are still not quite adapted to account for all of the nuances of purchasing software. As such, buying “software-as-a-service” in industry speak is very different from purchasing a software license via a service contract in government acquisition speak.
If the government has chosen to buy your product via a service contract versus a product contract, it may change how the line items are structured, the quality assurance and surveillance requirements, the contract deliverables, the terms and conditions, and yes, how your contract financing is structured.
If you aren’t sure, you can ask your customer or look for indicators in the documentation. For example, use of a Performance Work Statement (PWS) instead of a Statement of Work (SOW) usually indicates the government has categorized the acquisition as a service effort. If the unit of purchase is month versus each/lot/license, it is more likely to be a service contract. If there are clauses that say “for services” usually a good bet you are looking at a service contract. Likewise, if you see a Quality Assurance Surveillance Plan (QASP) as an attachment or proposal requirement, it is most likely a service contract.
To be clear, I am not suggesting that there is one correct way to purchase software. Because many procurement and fiscal regulations are unable to account for the eccentricities of software purchasing, neither bucket is an exact match. As a company, you should consider which option aligns more closely with your business model. Are you only selling licenses, or is there a service element that must accompany the license use? Do you sell those services separately or is it baked into the cost of the license? These types of factors may better align with one acquisition model over the other.
However, it really isn’t up to you as the vendor.
Ultimately, it is up to the government to decide whether they consider the acquisition better suited for a service or product contract based on their requirement. Contractors can usually influence this decision more in a sole-source environment than in a competitive one. However, the government will ultimately decide how to structure their acquisition, and contractors get to decide whether to participate in a competition or respond to a solicitation in a sole-source environment.
