I have had experience with ordering development​ of custom IT systems for my workplaces as well as adapting existing 3d party systems to our specifics.

Based on that experience, in your case I would proceed by narrowing down the task to be done until it is possible for the contractor to give you an estimate of hours needed to do it.

Note that depending on the size of project, the narrowing down itself could be quite a task. If you have qualified personnel for describing business requirements, it could be done in-house, otherwise this could be where some consultancy hours go.

Regardless, I wouldn't go into any project without contractor's estimate of expenses. After expenses - including billing for potential unforseen circumstances not due to contractor's fault are agreed upon,- the hours actually spent become somewhat immaterial. They still serve as basis for billing, but there is little point in arguing over +/-1hr as in software development it is hard [and in this case unnecessary] to control what exactly was done at which point.

I have had experience with ordering development​ of custom IT systems for my workplaces as well as adapting existing 3d party systems to our specifics.

Based on that experience, in your case I would proceed by narrowing down the task to be done until it is possible for the contractor to give you an estimate of hours needed to do it.

Note that depending on the size of project, the narrowing down itself could be quite a task. If you have qualified personnel for describing business requirements, it could be done in-house, otherwise this could be where some consultancy hours go.

Regardless, I wouldn't go into any project without contractor's estimate of expenses. After expenses - including billing for potential unforseen circumstances not due to contractor's fault are agreed upon,- the hours actually spent become somewhat immaterial. They still serve as basis for billing, but there is little point in arguing over +/-1hr as in software development it is hard [and in this case unnecessary] to control what exactly was done at which point.

EDIT:

To clarify. In my opinion and experience, it is bad practice to do hour and minute counting the way it was presupposed in the original question, because it implies lack of trust in contractor AND -- unless you are IT shop yourself -- you have generally little way of CONTROLLING him. So, you could end up arguing about hours in a situation where you frequently have no other (or no cheap) way to test his veracity.

So my approach would be:

1. The aim generally is to control expenses per result achieved, so the need is to narrow down the actual hours needed as much as possible beforehand. Let's say a task is estimated to take 40hours of development + testing, add to it ~10-20% max hours for adjustments due to incorrect business requirements, etc., and agree that after up to 50h of work you will have a working result with these parameters.

This is especially true in a pre-existing ERP system, which only needs to be adapted to your work environment. The existing functionality is there, so most adaptations can be described as changes to existing system -- usually much easier than building anything from scratch.

2. If it is impossible to know how much hours the development will take, the development tasks need to be subdivided or extra information about tasks gathered, until some definite estimates can be given.

3. If it is still impossible for contractor to give any estimates, which could form the basis of contract, the contractor is quite possibly not worth it.

Note that this goes contrary to some software companies' Agile-toted practices much seen these days. In my experience, Agile development shops tend to shift all the responsibility for the end result to the customer -- we will do whatever you say for $X/h. You didn't really know what you wanted? Tough luck.