I'm going to disagree totally with Bogdan's answer. I believe that, in most cases, it's better for the developing organization to supply the Product Owner. There may be cases where it does work out, but I'm hesitant.
The first thing to consider is why you are contracting with a software company instead of building the software yourself, internally. It's most likely because your organization doesn't have deep expertise in software development, but the firms that you have contracts with have that expertise. The expertise would include product management, project management, and requirements engineering in addition to the design, build, and test aspects.
Generally, I'm concerned when customers dictate the development process. This is partially for the same reason as above - the customer is contracting out the work because they do not have the resources (usually staffing or knowledge) to do it on their own. The development organization should bid on the contract based on their ways of working and then execute on that way of working. It is helpful when the customer is willing to commit to Agile Software Development since frequent involvement can help to get to the right thing faster through rapid feedback loops.
The Product Owner role is also a full-time job of working with the development team. By taking on the Product Owner role, you are committing to working your entire time to supporting the development teams creating that product. You are looking at involvement in backlog refinement, Sprint Reviews, and Sprint Retrospectives - this could easily be (4 hours * weeks in Sprint) + 4 hours + 3 hours per Sprint, give or take. Your responsibilities to this team would come before other obligations, otherwise, you are a bottleneck to the team achieving their goals.
I'd also point out that the Product Owner coming from the customer will likely lead to a bespoke software product. There may be cases where this is appropriate, but there may be cases where you exclude potential contractors if the structure or contract prohibits building something that could be leveraged as a platform for future work.
Generally, the best thing to do is to have a Product Owner that is from the same organization as the development teams creating the product and is fully dedicated to them. Anything else runs the risk of slowing the team down. It may be necessary for a Product Owner to ramp up, but the long-term benefits of close alignment between the Product Owner and development team outweigh the necessary ramp-up time.