Integrate with ERPNext Asset doctype rather than building our own Loan Security “ecosystem” of doctypes

[bosue]

Loan securities may be guarantees or assignments / cessions or actual assets.

Whenever they are assets, I can see no valid point in duplicating erpnext‘s Asset doctype, just with waaay fewer functionality and both a duplicated code base and scattered data structure.

Capitalized assets and non-capitalized assets, collateral assets (and the edge case of capitalized collateral assets)

In general, assets may be capitalized (and then depreciated) or they may not be. Mostly yes, sometimes not. This, however, isn‘t a black-or-white thing, it may rather depend on subtle differences, even if the company is legal owner, and may even differ between financial reports and tax statements.

The same may hold for collateralized assets, just the other way around. Legal ownership will mostly remain with the customer, but may in some scenarios, such as Sale-and-lease-back-transactions, even be capitalized and depreciated with the lessor / lender.

Finally it‘s all about conflicting fields of law. Tax code and their authorities always wants the company to state as much earnings as possible. Commercial law and regulatory authorities always want to stay on the safe side, tending to understate what may be capitalized. Civil law on the other hand will be searching for a systematic approach that reconciles all parties interests, playing the role of a fair mediator rather than an interested party.

Depreciation / devaluation

If the asset is not capitalized, there‘s of course no depreciation in the legal sense. But the reduction in collateral value that needs to be deducted over the months and years may still (have to) be scheduled exactly the way depreciations are implemented.

Or – if official depreciation rules are out of touch with reality, which they often are – we need a separate, more realistic set of devaluation rules. But in this case we may / will need them for our capitalized assets just as well, so we know what they‘re real market value is, no matter what the official depreciation rules may say.

More similarities

The owner documents of a collateralized security (e.g. a car) will mostly be with the bank, exactly the same way as for capitalized assets, so we need a register of vehicle registration numbers, vehicle identity numbers, vehicle registration offices, and various document handling procedures, standard letters and forms.

Even insurance or vehicle tax may (have to) be paid by the bank and included in the credit / leasing installments. So do we want two separate registers and two separate sets of documents and workflows, each siloed in a different Frappe module? No, certainly not.

Conclusion

Long story short: Everything the Asset doctype “ecosystem” including all its integrations may give us for capitalized assets would be valuable for collateral assets just as well, and the other way around.

So we definitely shouldn‘t reinvent the wheel here, but integrate with the ERPNext Asset “ecosystem“ and maybe extend it a bit so it caters to frappe/lending’s needs.

Thereby, we would earn a lot:

• Deduplicate code, improving maintainability
• Receive far more features and integrations from the ERPNext Asset doctype and its integrations
• Contribute back quite a lot of improvements and polish to the ERPNext Asset doctype, which in any case would become way more flexible and powerful, and – if we focus on UX ourselves – may still get easier rather than harder to use for all usecases.
• Avoid siloed data for capitalized assets vs. non-capitalized, collateral assets
• Avoid duplication of data if collaterals need to be capitalized as assets

(edited for clarity)

[anandbaburajan]

@bosue can you share any situations wherein a company would decide to capitalize a collateral as an asset?

[bosue]

@anandbaburajan: I will hopefully find more time to continue with my tickets this weekend.

However, while nomenclature may depend on jurisdiction, Sale-and-Lease-back transactions oscillate between a traditional Lease agreement and a loan secured by a collateral asset. Depending on various circumstances that may vastly differ between jurisdictions, accounting standards and tax bylaws, they may either be considered as one or the other. This may even change at certain points.

The short form is: Whenever considered as an agreement akin to Rent, the asset will be capitalized by the lessor (= operating lease), otherwise – if akin to a loan – it will be capitalized by the lessee (= financial lease). While the criteria whether it has to be considered as one or the other, may not be completely arbitrary, they however aren’t qualitative or categorial either, and involve several somewhat arbitrary cut-off lines.

The consequences of crossing such a cut-off line may be substantial in terms of accounting. But from all the other perspectives (contract, disbursement, repayment, handling of ownership documents, insurance etc.), you certainly don't want a completely separate process for a 36 months vs. a 37 months term or for the nuances between a merely secured loan, a Lease or SLB contract with formally fixed transfer/return of ownership (in both cases the asset will never be capitalized) or both a buying and a selling option vs. the 50 % standard case of a Lease or SLB contract with either of a buying or selling option and the 30 % case of a Lease or SLB contract with neither option (with the asset in most cases being capitalized, only in some cases not). For IFRS, see this, other accounting schemes do differ.

While obviously just nuances in terms of contract, this would still lead to completely different accounting facts.

Now you may say: frappe/lending is only aiming at traditional loans, with secured loans already being an edge case.

Would be sad, but even with traditional secured loans, the moment a secured loan becomes an NPA and is terminated and considered a default, what previously was just your collateral asset may become your full property, from that moment on to be capitalized and amortized. This even goes beyond material objects if a loan is secured by an assignment like, say, a life insurance claim.

Certainly we won't be able to implement all of this at once, and we don't have to. But we might want our architecture to be flexible enough so we or someone else may easily implement their individual financial product, just adding a missing part or two and some glue. And part of this would be a full-fledged asset management that may optionally include capitalization, depreciation as well as all the other things you can or have to do with an asset.

There‘s however never going to be two or three full-fledged asset managements with all the options for capitalization and amortization, depreciation schemes, guarantee, maintenance, insurance, ownership documents handling, location etc, possibly GPS location tracking and hedging (for mobile goods), possibly usage tracking (pay-per-use, pay-per-mile, maintenance intervals etc.), possibly access management…

In the end, there is either going to be a single one central asset management for all types of assets (fully owned and capitalized, loan collateral, even assets financed, borrowed or leased by the company itself that may still need tracking and maintenance and all the goodies) and thus would necessarily be living in frappe/erpnext, only to be expanded by custom fields and contrib functionality in a minor way.

Or there is not going to be anything like it. 🤷🏻‍♂️

[bosue]

And the best way to accomplish it would IMHO be:

• Merge all basic infrastructure to frappe/erpnext, just without the UI as far as it may live in connected doctypes, and without business logic and other stuff that may be plugged in, configured or easily customized.
• Merge everything even many non-financial companies may need, back into frappe/erpnext. This would certainly include basic stuff like interest timelines, interest day count conventions, certainly everything related to asset management, but should also include borrowing/financing/renting/leasing as a passive party, and even very basic use cases of lending such as the classic employee loan (HR in this case), loans between two or more parent/child or brother/sister companies administered by the same instance of ERPNext, loans by and to shareholders etc.
• Allow/help non-financial third-parties to build on the frappe/erpnext Asset management.
• Build on this in frappe/lending, fleshing out the classic Loan use case but remain open for further integration.
• Allow financial third-parties to build on frappe/erpnext and frappe/lending in their own financial product x, y, or z app.

All in all a large undertaking, but very much worth it, and doable as a step-by-step approach.