What are the terms of your contract? Did you specify having a user acceptance test phase? Did you make the payments contingent upon clearing UAT?
Have the modules / units / whatever been accepted by your organization? Note that there is a difference between received and accepted. Received means you have received the code and it is entering user acceptance test. Accepted means it has passed the UAT.
If the bug is found after UAT, you are generally bound to pay for the fix. If it's found during UAT then you haven't received working code yet, so the payment milestone hasn't been met.
If you didn't put any sort of acceptance provisions within the contract, then you're likely bound to be paying to fix the bugs.
I'm editorializing here - if you're in a condition where you don't have a means to enforce receiving code that works as expected, then ditch the contract now. The outside firm is only bound to deliver what is in the terms of the contract. If the contract doesn't specify what "functional" is, then you're pretty much at their mercy for what is delivered for final content.
Additional edit #1:
If you're in a "Time and Materials" contract for the development work, then there is no functional difference between paying for them to code new function or paying them to fix bugs in the new functions. Think of it this way: Just because they gave you a preview of a function doesn't mean that the function was actually delivered. So while you may have found flaws within the function preview, that just means they're not complete with developing it yet. What you see as bug fixes is really their continued refinement of the function.
Additional edit #2:
I would encourage checking to see if you formally moved from the fixed price contract to the project-log / by-the-hour (aka T&M) approach. In general, I have never advised any of my clients to accept a T&M contract when it comes to new development. There are simply too many variables in play to make a T&M contract an acceptable risk.
In a fixed price world, they are bound to fix any and all issues that prevent delivering the function specified by the contract. So bug fixes would be on their dime, not yours.
In a T&M world, there is no such thing as a bug fix. It's just additional enhancement of the code that has been generated at that point in time.
(Editorial #2) If things are bad, don't be afraid to ditch a bad contract. Pay the escape penalty and be done with it. It's very easy to get into a situation where good money is thrown after bad. Stop the bad development process; re-work the RFP and specify what is actually required; ink a new contract. It's the best way to make sure you'll get what you actually need and will save a lot of headache in working through a bad contract.