projectfacts in your system landscape

The most common case among service providers. Quote, project, time recording, ticket and invoice arise in one system and belong together. Only two things go outside: the financial data to accounting through the DATEV interface and appointments, contacts and emails to Microsoft 365. Everything else stays inside. What comes together in the process is shown in the complete overview of functions.

Where a merchandise management system is deeply established, replacing it would be a project in its own right, and it is rarely necessary. projectfacts then takes over the areas that classic ERP systems cover poorly: project management, time recording, ticket handling and the billing of services. The connection runs through the REST API, which brings master data in and sends results back.

If figures sit in five systems today and nobody brings them together, the hub is the real task. projectfacts collects the data, links it up and passes it on in an orderly form, either to a reporting tool through Power BI and the export or to a higher level system. If whole siloed tools are to disappear in the process, the page on replacing siloed tools is the right place to start.

For the most common systems the connection has already been built and only needs to be set up: DATEV, BMD for Austria, Microsoft 365 and Teams, the bank interface, calendar and contacts, email and the telephone system. That is always the shortest route, so check it first.

For everything without a ready-made connection. Through the open interface, other programs read and write the same data your employees work with. The right route for fixed, recurring processes that are meant to run unattended.

The youngest of the four routes. Through the MCP server, an AI assistant accesses projectfacts and answers questions that would otherwise require someone to build a report. Not a replacement for the API, but the complement for everything that cannot be planned in advance.

The least spectacular route and often the quickest. Lists and reports go out as CSV or Excel and from there into any tool that can handle them. For one off questions and for recipients who do not want a connection.

There are two routes to choose from. If your accounts sit in Microsoft 365, your employees sign in through single sign-on with their Microsoft account. If you manage your users in your own directory service, projectfacts checks the sign-in through Active Directory and LDAP. In both cases, access is withdrawn in the place where you administer it anyway.

The permissions you maintain in projectfacts apply in the interface, through the API and through the MCP server alike. No access route gets special rights simply because it comes from outside. That saves you a second permissions concept, which otherwise quickly drifts apart from the first.

Everything held in projectfacts can be exported, through the API and through the export functions. That is not a footnote for the event of a parting of ways, but a practical question: a system you can only get data out of with difficulty makes every later decision expensive.

First the area where the greatest pain sits, usually time recording and project management. Then the adjoining areas follow, and only at the end the connections to neighbouring systems. Anyone who works the other way round and starts with the interfaces builds connections to processes that are still going to change. How an implementation actually runs is described under implementation process.

If you work across borders, currencies, tax rates, leave and public holiday rules come into play. These building blocks do not hang off the country but off the master data, as described under international use. If your company belongs to a group or has been acquired, the page on group integration is the right place to start.