Added project-based accounting

63

@sarwat this is something that I want to implement across more than just projects. Sometime you want the same tax code on each line item. So instead of selecting it manually on each line item, you can set the one for entire document. The same goes for projects, divisions, discounts etc.

3 Likes
64

That is not practical, because you might have line items on a single transaction for multiple projects.

2 Likes
65

thank you, and best wishes for you Mr. @lubos

66

Yes some time we purchase items or services in our purchase invoice from a supplier but we assign them to different projects. so project next to each line items is doing good

67

Dear Lubos,
the tax rate on line items is doing much better than a single tax rate selection for an invoice.
item unit price qty amount tax rate total amount
item1 1000 01 1000 17% 1700.
service1 1000 01 1000 16% 1600.

so the way it is is good for all i think.

1 Like
68

I completely agree with @naseerkhattak. I think the ability to set and change tax codes at line level is a must.

However, I wouldn’t oppose a shortcut method to fill all lines, provided that it’s completely optional and undoable.

3 Likes
69

I think the sales order idea is good. It can actually kill 2 birds with one stone because when the sales orders are presented in some form of workflow/flowchart, combined withcustomer/supplier portals, can give birth to a bid management system that ends in an award of tender to a supplier. Basically a procurement module.

70

I originally was in favour of the sales order handling everything, but I agree with the developer that the sales order should track delivery/invoicing and projects should track profits. Otherwise there is too much information in the sales order and more importantly you are limited to one sales order to one project which is very often not the case. Usually several sales orders will comprise one project.

The customer would never see or know what your profits are per project. The sales order can and does integrate with the customer portal and will show delivery and invoice status.

What exactly are you proposing that the developer do instead?

71

Of course the programmer is speaking from a position of knowledge and authority. But I think this duplicates what class tracking can already do. I am not very smart but I think projects may be created as classes for purposes of reporting profits/surpluses? Making some kind of workflow wizard, in my opinion, would make it possible for sales/purchase orders, sales/purchase invoices, debit/credit notes to be allocated to a specific class for tracking and reporting.

72

I think that you may be talking about a different requirement. What the project module is about is a specific project - for example you are building a house for a customer. So all the work, invoices, billing time etc is all tied up in that one project.

Class tracking I believe is when you allocate say televisions and laptops to electronic class and carrots and bananas to groceries class and you can track profits on these “divisions”. Otherwise I am not really sure what you mean by class tracking. But the developer can answer your question better.

73

If you mean that projects are just duplicating what divisions already do. I’m very careful not to introduce new features which are just different name for something already implemented elsewhere.

The difference between projects and divisions is that projects are tracking profitability for management purposes. Divisions are tracking profitability for accounting purposes.

This means if you order something from supplier (e.g. by entering purchase order), the cost on the order is included in direct expenses for the project right away. You can see how your project is doing even if suppliers are delayed sending you invoices. Projects also consider income and expenses recorded against balance sheet accounts as simply income & expenses.

Divisional reports do not consider purchase orders at all. Divisional P&L is not affected by entries in balance sheet accounts. This means you can get proper divisional P&L and balance sheet while with projects, you really just get summary of income and expenses (and some expenses can be in the form of purchase orders).

I’m sure as this feature evolves, the difference between divisions and projects become even more apparent.

2 Likes
74

It is fundamentally incorrect to suggest that Management and accountant’s profit can be different. The profit can only be different if you are talking about cash accounting or accrual accounting.

That said, in my opinion, if you make it possible for budget/projection lines to be displayed next to each class/division, you have your project accounts. All other accounting processes remain the same. Only thing is to users to select a class/division to a source document. Also enabling sub classes/division may enable one to say have several business divisions with one division dedicated to projects. Where one has more than one division then they can create subdivisions of the main project division.

The budget/projection can then be compared with actual accounting data and the percentage of completion of a project arrived at and Gantt charts plotted.

Where cost of project cannot be projected, then incomes and costs are accumulated as in a normal division.

User rights can be twerked to limit user access to various projects.

75

Maybe you are right. But I’m not so sure. After all, this argument could have been used when someone proposed cash-basis accounting. Someone could have said it is fundamentally incorrect to suggest there could be two ways how to measure profit.

If you are right, we will all come to the same conclusion eventually.

1 Like
76

I agree with @Lubos initial assessment here and I will have to strongly disagree with @EPR_Capital on two these two points:

  1. Divisions are fundamentally different from Projects.

  2. “Accounting” profit and “Management” profit are expected to differ in the context used here. (Not that I agree with the terminology here, but I digress for now)

I’ll try to separate the two issues to the best of my ability despite the temptation to do so.

Divisions vs Projects

  1. Divisions have indefinite lives while Projects have a beginning and and end. The implications here are countless like the limited number of Divisions vs the limitless number of Projects, and Projects overlapping reporting period, just to name a few.

  2. Divisions are master records while Projects are transactional records.

  3. You can allocate accounts and transactions to Divisions but you can only allocate transactions to projects. This is party due to the fact that accounts like employees and customers, etc. are master records that are going to outlive the projects and possibly contain transactions of Tens, Hundreds of thousands or evem Millions of projects.

  4. Divisions and Projects are on completely different dimensions and they can intersect. Example would be when you have a Marketing Firm that has two divisions: Branding and Events. A single project can be shared by both divisions and the only way to capture the true nature of the situation is to separate divisions from projects in two separate dimensions, exactly like what we already have. Combining the two will result in significantly reducing the capabilities of Manager.

  5. Continuing no 4, since they are separate dimensions, you can’t have both in a single table and show a total. It’s not like apples and oranges, it’s much worse here and it will result in double counting.

Accounting vs Management Profit

It’s not really a matter of “Accounting” vs “Management” profit since they are almost - but not exactly - equal most of the time. Rather, it’s a matter of what expenses can be objectively and directly attributed to an activity, which is in our case “Projects”, hence the specific issue we are discussing here is “Activity Based Costing” or ABC for short which is a subset of Management Accounts.

There are tons of examples of expenses that cannot be attributed to an activity unless you don’t care about having misleading information. These expenses do not vary with any of the cost drivers of your project such as:

  • Idle capacity which can basically include every expense category under certain conditions. Allocating this to projects would result in substantial overcosting, uncompetitive pricing and missed sales opportunities eventually.

  • Side business activities like sale of Assets both gains and losses. How to attribute those?

  • Admin expenses like Management’s benefits.

  • General expenses like repairs and maintenance. It’s already impossible to attribute maintenance expense of a production tool over all the jobs it did, let alone trying to attribute the maintenance of an Admin asset.

  • Regulatory expenses like pensions and other benefits. E.g. It’s nonsensical to subdivide pension liabilities of a staff based on a project.

Certain expenses can’t be allocated to activities because they will definitely distort the reality of the situation. In order to get a correct project cost, you will have to have Cost-Volume-Profit “CVP” relationships built into your costing and that entails intentionally excluding certain types of expenses.

That’s why I am strongly opposed to forcing the total project costing to tie in with the P&L because that is fundamentally and demonstrably wrong and will definitely result in wrong and costly decisions.

Maybe @EPR_Capital your business is an edge case where division and projects are more or less the same and all your expenses are directly attributable to Projects, I don’t know that. What I know for sure is that 9 times out of 10, that’s not the case for most busineses. So we can’t have Manager force wrong methods on all users because it suits some edge case.

3 Likes
77

Fixed costs (overheads/indirect costs) should be allocated to activities (projects) on a fractional commensurate basis where the activities use resources associated with the fixed cost/s. Whether it is best to include this in the Manager project module is another question, but if not, fixed costs should be allocated to activities(projects) outside of Manager at some point.

Accruals would need to be done for holiday leave, Long service leave, employer superannuation contributions, and payroll tax, to enable allocation of these types of costs. A CVP analysis will always allocate relevant fixed costs to get a break even point.

Project surplus/deficit will vary from accounting surplus/deficit where the output of the project is capitalised within the business. e.g. building a new head office.

78

The Cost-Volume-Profit (CVP) analysis you are discussing is company-wide Break-Even Point (BEP) or Target Operating Income (TOI), but what I discuss is the CVP relationships in general and how they apply to a single project. Sure you can include almost - but not quite - every expense if you’re selling a single product and you want to know your company-wide BEP or TOI.

But if you break things down into categories, how would you allocate idle capacity for example across projects that have no idle resources sitting around? Remember Idle capacity is the result of having no projects to allocate wasted resources to so how can you distribute that on segment of Zero idle capacity? Assigning idle capacity to a project working at full capacity is logically equivalent to dividing by Zero. And I already discussed the Management pitfalls of doing so.

And there are countless examples in management accounting textbooks on why you should leave certain categories of expenses out of certain management reports and how that would adversely affect your decision making.

It’s not a matter of if they should be left out, it’s a matter of when it’s not wise to include them. And that’s a long and complicated subject to discuss in a forum and that’s why I will just leave it at that.

Edit: You can check this :point_down: out as a quick reference, but I would still prefer if you dig in deeper into the matter and you’ll be surprised about the hidden costs of improper cost accounting. Your choice of costing methods could literally make you or break you.

https://learn.financestrategists.com/explanation/cost-accounting/items-excluded-from-cost-accounts/

79

I don’t think that we disagree that not all fixed costs should be allocated to projects. I was concerned that the impression was conveyed that it is not important to consider allocating fixed costs.

Yes, taking this discussion further would be well beyond the scope of this forum

1 Like
80

The more I listen to the thought behind the Projects tab the more I am convinced that it is unnecessary and can be achieved by extending the divisions function.

First I agree that Projects and accounting are fundamentally different and that project management is a not an accounting function. It is a management function.

Projects however depend on the accounting data and in essence, is an analysis and presentation of accounting data in a manner that makes it easier for management make informed decisions about a business/organization/branch/segment/project.

Let me try to give a direct response to your numbered points.

  1. Projects have definite lives yes, but the accounting data in relation to the project is permanent data and forms part of the accounts.

  2. If by master records you mean is a “Fixed Overhead cost” then you know that in practice, Management accountants use a “Fixed overhead absorption rate” which is basically a method of allocating overall cost to specific project/division.

  3. It is possible to allocate transactions to a division. Where a cost cuts across several divisions, then it is an overall cost and usually, in practical situations, is normally called the Administration Expenses. During management reporting, the ratio in 2) above is used to allocate the overhead costs. E.g the Manager’s salary is an expense that may need to be allocated to various projects depending on say how much time they spend in each project. This can be done by simply having custom reports for divisions.

  4. Again I think this is a matter that can be solved using reports. In your example, it is clear that 2 divisions have come together to form a third division which has to be named after the project. Again keep in mind that Projects are simply a manner of expressing accounting data in a manner that gives management a better view of the situation for purposes of making a decision.

  5. I am not a programmer and may not know how it is achieved, but I believe projects should just be under reports. The data will already be there waiting to be queried to achieve the many project reporting and project management models. All you need is an extra column during the creation of a division that allows a user to toggle between creating the division as a division or as a project for purposes of separating projects from division for reporting purposes.

Lastly, by suggesting that the total project costing, and by extension the profit/loss calculated therefrom, can be different is in essence agreeing than one of the records is indeed wrong and incorrect. If daily accounting data is correctly captured, project reports have no option but to be correct.

81

Hi @EPR_Capital. I will respond to your last point first

I think we already discussed why this is wrong. Plus I don’t think the principles of management accounting is up for debate.

This :point_down: could be the starting point to your quest for enlightenment. :grin:

Aside from that,

No, master records is an IT term for permanent records that are not transactions. This is a very important distinction to make if you want your database to run efficiently and without errors.

Projects aren’t master records, they’re just a collection of transactions with additional information like start dates, end dates, names and overhead estimates.

Divisions on the other hand are master records.

Of course, If I understood you correctly, you aren’t concerned with what’s happening “under-the-hood” of Manager but you want them to appear together on the surface because that seems more logical.

But there’s some other problems here which are:

  1. While it may seem logical to some users like yourself to combine the two on the surface, other users like myself find it more logical to separate the two. This is purely a matter of preference.

  2. Combining the two means you will not be able to set different user permission for Projects and Divisions. I don’t want that to happen since Divisions are a set-it-and-forget-it type of deal but Projects are a constantly being created and edited so I don’t want to expose my Divisions to the risks of that kind of traffic.

  3. This also means that Manager will have to combine two unrelated views (IT-wise) as one which has some effects on performance but also, this goes against the transparent design used by Manager. You’ll never find this kind of combination anywhere else.

82

I think major distinction between project and division comes like this.
One division may serve many customers and each customer may be having different projects. Accordingly, the sum of projects in a division should make the figures for the division.

But there may be instances where different divisions together cater the requirement of a given project.

According to my understanding, divisions and projects serve two different purposes and both have their own merits.

Even the same customer may be dealing with many different goods/ services/ projects served by isolate divisions as well as collaboratively with other divisions.
Example Big 4 firm has several divisions like accounting, auditing, valuation, etc. Provided independence is not compromised, client regularly dealing with accounting advisory division may get separate valuation service from valuation division. At another time, accounting division may deliver the project collaboratively with valuation division.

2 Likes