Where does complex application logic belong in MVC model?

So I have an express app. I use MVC model, I have Sequelize for Model layer, Handlebars for View and Express for Controller.

My app does some trivial manipulation with DB, I achieve this by extending Sequelize functions and using the Model as much as possible from inside the Controller.

However, I do have some more complex tasks which:

• work with multiple Models
• have to perform additional network data retrievals and calculations
• change many things inside DB.

Where do I put this code according to convention to maintain readability?

• I cant put it into models/ folder, it is not a Sequelize Model class
• I cant keep it inside controller code, this lowers re-usability of this code and bloats my controllers
• I cant put it into separate file inside controllers/ folder as it is not express-compatible function, therefore not a controller per-se.

I do have utils/ folder, but that seems just like a lazy choice. Ill end up with random functions I have no better place for in one place.

Where do you guys and gals put such code in your apps (code which works with Models and yet is not a part of a single one)?

EDIT

I ended up with

db/
---models/
---interactors/
------invoicing/
------user-manipulation/
...

structure

My experience is that you'd have a service layer, or business logic layer.

You can structure it in the obvious way were you have individual folders for controllers, services, models, etc. Or do a modular or component based structure that is grouped by the model/API type where users would include the user-based files. When working with multiple models, services can depend on other services and controllers can depend on multiple services but make sure the controller doesn't have any business logic.

Notice in the link where it says:

It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

For an MVC application, this implies at least four layers. Models, views, controllers, and services; this is pretty common to see. But it can also be valuable to pull the db access out into its own layer as well. This way you're not bound to a particular storage type, vendor, or framework and it aids in testing. This would be where the ORM usage would be for example and used by the services.