use case: reconcile virtual accounts with real accounts

[ahdinosaur]

currently within Enspiral we're having a conversation about our internal accounting system: "my.enspiral". since i'm most keen to build a system that works for Enspiral, i'll be extracting some feedback on our current system into user stories and design requirements here.

the main requirement (and current pain point for our accountants) is to ensure a set of virtual internal bank accounts are reconciled with actual external bank accounts. missing transactions on either side means more manual work for accountants and chance for errors.

• virtual accounts must track respective actual accounts and vise versa
  • must include accounting of tax paid, tax yet to be paid, future refunds, etc
  • must include a mechanism for detecting missed or incorrect transactions
  • must be consistent with the "matching principle” - the concept that expenses are recognised in the period that the related income is earned

[bhaugen]

We haven't done this, but one idea that we are thinking about is that of underlying resource, where the underlying resource for a virtual account that is part of actual bank account is the actual bank account.

Does that make sense?

Not totally sure what the other issues mean, but I could yell at some REA accounting experts who might be willing to help. I think I understand REA intimately, but not all the ins and outs of conventional accounting. Especially taxes.

[ahdinosaur]

We haven't done this, but one idea that we are thinking about is that of underlying resource, where the underlying resource for a virtual account that is part of actual bank account is the actual bank account.

Does that make sense?

yeah that makes sense.

[fosterlynn]

@ahdinosaur I'll be interested in your user stories....

[ahdinosaur]

@ahdinosaur I'll be interested in your user stories....

same here, i'll try and work with the relevant people in Enspiral to digest the feedback on our existing system into actionable user stories and design requirements, will report the results of that back here.

[bhaugen]

@ahdinosaur - this initiative ever go anywhere?

[ahdinosaur]

@bhaugen

hehe i saw that you went back and read the Enspiral thread about this, really happy that you're able to see those conversations first-hand. :smile_cat:

so, as far as i know about the progress of this initiative: my.enspiral continues to be a significant part of Enspiral (Services), so the demand for its improvement is as present as ever, just a question of who's carrying it. and it seems it's being picked up by charlie, who is working with the (recent success story) Ops team to improve it for their requirements.

[bhaugen]

@ahdinosaur yeah, been inhaling the firehose for a couple of weeks. Thanks for carrying the torch for VF.

I see evidence of Charlie working on the short term needs. I was most interested in what Alanna and others mentioned about the research needed for the next version. Seems like we should be able to help with the accounting requirements. I can recruit some of the REA community to help if need be.

[fosterlynn]

If this gets going again in Enspiral, I'd be happy to put some time into Exchange vocab to support that, if people there want it. (I've come up for air, got the bulk of the exchange re-write done in NRP, looking forward to getting back into VF.)

[ahdinosaur]

@bhaugen: I was most interested in what Alanna and others mentioned about the research needed for the next version. Seems like we should be able to help with the accounting requirements. I can recruit some of the REA community to help if need be.

@fosterlynn: If this gets going again in Enspiral, I'd be happy to put some time into Exchange vocab to support that, if people there want it.

since "the next version" will "get going again in Enspiral" in a matter of time, and when it does happen we might already be too late to guide vocab and designs, what if we were proactive and did some sprints with this as the focus? just a thought, especially keen if it brings out some of your recent work with NRP.

[bhaugen]

@ahdinosaur - I'm in. I'm looking at the current data model to prep a bit.

But we'd really need somebody who has fairly deep knowledge of several of the problems Alanna mentioned.

By the way, I am not personally angling to guide vocab and designs for the next version of my.enspiral. I am thinking of it mostly as a great use case for value flows. If I can help my.enspiral too, that would be wonderful, but also seems presumptuous. You and @simontegg could definitely help my.enspiral, and I might be able to help you, but I feel like I am too far away from the context and have really modest expectations about how much I personally could help. But I would try like crazy.

[fosterlynn]

@ahdinosaur I'm in!

As a note, in my latest code round, I split out Transfer, and am using Give and Receive (usually called Take) event types within a Transfer. Exchanges can group Transfers.

What I didn't do is "underlying resource" - the my.enspiral virtual accounts would be a very good use case for that; and we have virtual accounts in Sensorica too, addressed but not very well yet.

[fosterlynn]

@ahdinosaur @bhaugen what is the best way to get going on a sprint? I would need to understand the requirements or user stories or use cases, as they are currently understood.

[ahdinosaur]

@fosterlynn stumbled on a recent my.enspiral hangout that does well to capture the core ethos: a virtual ledger backed by an actual bank account.

rough draft use cases from video:

• as a user
  • i can login to my.ensiral
  • i can see all accounts i have access to
  • i can see transaction history of a given account
  • i can see the current balance of a given account
  • who is authorized for an account, i can transfer money in, out, and between accounts
  • i can see outstanding (pending) invoices on account
  • i can make a line item in an invoice (in Xero) to note that a percentage of invoiced money should be given as a contribution to collective account (e.g. i invoice for $1000 at a 20% contribution rate, it will show up as $800 pending in my account and $200 in collective account, then when invoice is paid the accounts will automatically update appropriately)
  • i can generate a report for transfers in, out, and between accounts (e.g. to be used as an import into Cobudget based on how much people have contributed to collective account)
  • * i can setup commitments for how to automatically distribute money that comes in to an account
• as an admin
  • i can see all invoices
  • i can mark an invoice as paid
  • i can editing contribution rates or allocations
  • i can manually split up incoming money when invoices are paid
  • i can create new companies (based on actual legal entities, which means each company is "financially firewalled" from another, unless they invoice each other for legitimate reasons)

[bhaugen]

From Alanna in Loomio (copied with permission):

would caution @simontegg and @ahdinosaur that we may disagree about the right approach to this project. It seems you're jumping straight into issues around technical implementation and how to visualise money flows, etc (from what I can understand on the GitHub discussion). I see the important issues here as not very much about that, and much more about the challenges around how to interface the money flows with legal, accounting, and company policy and structural issues. These are the really sticky bits, and where I see the compelling potential for social impact.

The power of my.enspiral will come when we can offer the software with a whole lot of context about how it can successfully integrate with core business systems. Without that we're not really doing much to solve the hard problems for people, regardless of how the software works on a technical level. If we can say "here's how to set up an LLC and do your invoicing and accounting and taxes in a way to enable these peer to peer money flows, and here's how to understand and utilise the functions of a bank in this system, and here's how this is a logical and legal system for compensation of workers that won't get you sent to jail or sued" then we can track the accounts themselves on a spreadsheet and it will be 90% of the way there. It's not really about the software design - that should flow on from solving the business process questions, not the other way around. Not to mention the deep thinking that will need to go into a business model for the product itself, which will need to be conceived in an integrated way with the technical innovation.

This is also why I feel it would be best for people to direct their energy toward helping Enspiral Ops, Accounting, and Services sort out these sticky issues around tax, employment contracts, etc as the first priority. If we can crack that, then we'll really understand the power and potential of my.enspiral, and how it can be a transformative tool for running a new kind of company (which is like a microcosm economy/society, which is super exciting). And solving those issues will also help Services continue to be an engine of revenue for Enspiral as a whole, which should help resource further research on the future of my.enspiral.

[bhaugen]

@fosterlynn asks when Alanna made that comment: 5 months ago. In other words, it is not a comment on what we are doing here now, just surrounding conditions to inform some use cases.

[fosterlynn]

@ahdinosaur thanks for the requirements! Question:

i can create new companies (based on actual legal entities, which means each company is "financially firewalled" from another, unless they invoice each other for legitimate reasons)

In this situation, does a new company have its own real bank account, or is that also a virtual account within the one real bank account? If the latter, what does "financially firewalled" mean? A permissions thing? A viewing thing? Is there something different about this situation than any other permissions to transfer funds between virtual accounts?

[bhaugen]

One other aspect of my.enspiral that I am absorbing from Slack chatter: it apparently takes the Enspiral ops team quite a lot of work to administer the system. I'm not sure what is all involved with that, but if a new system could ease that burden, it might be welcome. We'd need an ops person in the conversation to understand all that.

[bhaugen]

So, assuming we all want to do this at least as a VF use case, and maybe as active participants in a redesign project, how do we engage those of us who want in with the Enspiral team that will be working on it? Will they be interested in working with VF, or will we come on like these uninvited guests trying to get in on the punchbowl? Or know-it-all busybodies?

[fosterlynn]

@bhaugen those are very important questions. In the meantime, it is an interesting use case, even if we don't get invited, so I'm jumping in. Hoping not to offend anyone!

A very preliminary scoping exercise, using @ahdinosaur list above:

• Resource (the virtual accounts and the underlying resource of the actual bank account, with a relationship)
• Resource Type (need those to do Resource pretty much) - might be "Virtual account", "Bank account"
• Transfer (includes a Give event and a Receive event, to create the flow of value)
• Value Flow (aka Economic Event)
• Commitment (don't know if this is the best name - a plan, a requirement, a commitment for a future event to happen)
• Exchange (maybe, or not - groups Transfers where a Transfer is reciprocal for another Transfer, not sure this is needed)
• Agent (the person or group involved at each end of a Value Flow - but we basically have Agent spec'd already)
• Agent Resource Relationship (possibly, although this can possibly be derived from the events/ flows; one thing that makes this useful beyond the flows is that you can define different types of rights - ownership, usage, etc - although in this case it all sounds like ownership; and maybe the types of rights need to be modeled differently than this anyhow, connected to the flows, will require some thought)

It also may be that we are getting into the realm of distributions based on value equations, although this is a very simple use case of that (the 20% or 5% passed along). This might be too big a can of worms to tackle in this scope, remains to be seen. It can be laid on top of all the rest as needed. Which I suspect it really isn't yet.

[bhaugen]

my.enspiral does not actually get into the whole set of value flows, because time reporting goes directly into Xero. Take a look at our original Enspiral use case, especially . I think we should include all of that in a VF use case, not just the part that is in my.enspiral.

[fosterlynn]

I think we should include all of that in a VF use case, not just the part that is in my.enspiral.

I can see including all the transfers, that rounds out a view of the flows. I'm hesitant to include value equations initially because it is so huge. Maybe as phase 2? We would need to include the results of the value equations - the distribution. In my recent NRP work, I left the distribution event types as they were (Disbursement and Distribution), in the interest of breaking up the work. Maybe those should just be Give and Receive and part of Transfers, will need to discuss as a group.

Not sure we want to treat this scenario as work events - maybe better as services? Stay in the realm of exchange rather than process since the process is outside of Enspiral I think?

[bhaugen]

Agree about omitting value equations and processes. I think what they do is different from value equations a la sensorica or any other networks we have looked at for income distribution (e.g. Guerrilla Translators). I suspect the way Enspiralites think about it is the income is basically going to the service providers with some contributed to the collective. More like a tax than an income distribution. That's true of the x% for Sensorica, too, but there the income distribution is a lot more complicated.

[ahdinosaur]

@fosterlynn says: In this situation, does a new company have its own real bank account, or is that also a virtual account within the one real bank account? If the latter, what does "financially firewalled" mean? A permissions thing? A viewing thing? Is there something different about this situation than any other permissions to transfer funds between virtual accounts?

each company has it's own real bank account. in the current legal system each real bank account is "financially firewalled" from another, as in you can't legally send or receive money without a legitimate reason. this is why virtual accounts are awesome, you can legally send and receive money between people (for funding internal projects, paying for internal services, etc) as long as you do it within a legal entity with a real bank account. does that answer your questions?

[ahdinosaur]

@bhaugen says: One other aspect of my.enspiral that I am absorbing from Slack chatter: it apparently takes the Enspiral ops team quite a lot of work to administer the system. I'm not sure what is all involved with that, but if a new system could ease that burden, it might be welcome. We'd need an ops person in the conversation to understand all that.

yeah, one key learning from being in Enspiral is that it's most important to focus on admin (ops) requirements and use cases above all others. i've done my best to be involved in conversations with the Ops team and plan to continue, recommend it as a general strategy.

[ahdinosaur]

@fosterlynn says: I'm hesitant to include value equations initially because it is so huge.

@bhaugen says: Agree about omitting value equations and processes. I think what they do is different from value equations a la sensorica or any other networks we have looked at for income distribution (e.g. Guerrilla Translators). I suspect the way Enspiralites think about it is the income is basically going to the service providers with some contributed to the collective.

:+1: on omitting value equations and processes for any initial phase.

yet, there is a related pattern becoming more clear in Enspiral, which @joshuavial hints at in the video, about creating "service-level agreements" between groups in Enspiral. as an example, the Ops team has a "service-level agreement" with both Enspiral Foundation and Enspiral Services to do a specific Scope of Work (full internal document). i tried to capture this as "as a user i can setup commitments for how to automatically distribute money that comes in to an account", but really that's only one way these SLAs could be implemented.

@joshuavial, if you have any time i'd appreciate any more detail on your thinking with "service-level agreements" use cases and what user stories you wish were possible.

[joshuavial]

I don't know if it fits but with your thinking here but I have been doing work on 'product agreements' which define how revenue is split between pods. This doesn't attempt to define what a pod needs to deliver as part of that agreement, just how the revenue is split.

For example at Dev Academy we have been exploring a product agreement for our bootcamp where 30% of revenue goes to teaching, 60% to support and 10% to core. I am kicking around ideas with folks to define a role called product stewards who are responsible for maintaining this agreement as well as the quality of the product as a whole.

[ahdinosaur]

@joshuavial yep sweet, that's exactly what i was hoping for, thanks for clarifying. :smiley: keen to follow your progress on this (and be a sounding board), as i'm interested in how we might design technical infrastructure to support (and automate) the process.

[bhaugen]

I'm assuming "ask forgiveness rather than permission" for excerpts from relevant Loomio conversations, but I'll try to stay really relevant and use discretion. Like this one:

Anna-Marie

A question from a Newbe.

It states that Enspiral ventures contribute a voluntary amount each month. How does this align with work done under the auspices of Enspiral Services where I believed the expected contribution is set at 20%? Am I confused?

Alanna Krause

Don’t confuse Enspiral Foundation and Enspiral Services :) (which is easy to do). Enspiral Services internally has its people contributing a default 20% to collective funds (which is also variable, btw). Then Services contributes a set 5% of that total to Foundation. If Services wanted to change that 5% to another figure, they could.

Craig Ambrose

I think that this could be a significant problem: “Payments from the Foundation for buckets are only made upon completion of work, reporting of the outcome, and receipt of an invoice from the payee.”. Just about every bucket I’ve ever run from either foundation or services has needed to spend most of the money well before having an outcome. The only time where that isn’t the case is if the bucket proposer is offering to perform some labour in return for money.

Alanna Krause

Unfortunately operating on a reimbursement basis is really a necessity to make the process feasible for Ops to run, and to have accountability. What’s the alternative?

Craig Ambrose

@alanna I can see how it’d be easier to administer on a reimbursement basis.

You ask what the alternative is though. Well we’ve been running in for a couple of years now not on a reimbursement basis, but have distributed the funds into my.enspiral as soon as the buckets were funded. Hasn’t it worked pretty well?

Alanna Krause

I think you’re talking about Service collab funding in that case? Foundation has always been on a reimbursement basis.

Craig Ambrose

You’re right. I think my confusion is that I’ve had some buckets through services which were fairly enspiral wide, like childcare and so forth. Those certainly needed to be paid as they went.

Billy Matheson

Nice one @craigambrose. I was part of a really interesting conversation today about the (hidden) admin costs of some bucket projects. As I start year two of being involved in Enspiral the challenge and complexity of some of our innovations is slowly becoming clearer. I think that advancing small sums has been doable but my guess is that we will be moving to fewer larger buckets as we grow? Perhaps we need a loan/overdraft facility to enable bucket reimbursements? Of course that raises the whole credit/risk/boring etc…

Mikey

I think that advancing small sums has been doable but my guess is that we will be moving to fewer larger buckets as we grow? Perhaps we need a loan/overdraft facility to enable bucket reimbursements? Of course that raises the whole credit/risk/boring etc…

i’m imagining #enspiral-seeds: an Enspiral venture focused on providing on-demand loans via capped return investments! /cc @anthonycabraal

but also i reckon it would be great for Enspiral Services to be more clear on how we enable instant bucket funding through overdrafts and shared collective risk. i hadn’t realized the discrepancy with how the Enspiral Foundation does bucket funding.

[fosterlynn]

@ahdinosaur I am starting to think about this use case, and have a few questions, to make double sure I understand. They relate to this sample data.

1. When someone in Enspiral Services does some work for a client, does ES bill the client and receive the money? Or does the person doing the work bill the client and/or client send the $ to the person who did the work?
2. I understand the person who did the work can decide if the 20% guideline is what they want to do. How does that work if ES receives the money? Does ES then pay out the 80% to the person after asking the person if that is OK?
3. When ES offers services to clients, do they offer them by person and skill? Or one or the other? Or another way?

Thanks in advance! :)

[fosterlynn]

@ahdinosaur Also,

1. Do the account managers for ES (non-billable) get paid for their time? If so, how does that $ flow?

[ahdinosaur]

When someone in Enspiral Services does some work for a client, does ES bill the client and receive the money? Or does the person doing the work bill the client and/or client send the $ to the person who did the work?

the "project lead" is responsible for billing the client as ES, so the client will send the $ to ES. (docs on this process). in this invoice is where the contribution rates are specified (as that goes into a line item in Xero, not sure if the client sees it).

I understand the person who did the work can decide if the 20% guideline is what they want to do. How does that work if ES receives the money? Does ES then pay out the 80% to the person after asking the person if that is OK?

money is always paid into the ES bank account. the contribution rate determines how much goes into your personal my.enspiral virtual account, which you can pay yourself with (as an ES employee, you request to be paid via payroll; as an ES contractor, you invoice ES to pay you).

When ES offers services to clients, do they offer them by person and skill? Or one or the other? Or another way?

at the moment, ES is an invisible brand, so we never trade as ES. at the moment we are structured into teams, the largest of which is Enspiral Craftworks, but even Craftworks is very much a "hunt and kill" model where we are a loose swarm of freelancers (so very different from a traditional service agency). we're still figuring out how to offer our services to clients, i've heard both approaches presented before and at the moment we make it up as we go. our general structure and how we approach consulting is something i'd like to change in the near future, based on learnings with how we structured Enspiral Academy and the consulting team there, which is going into an ES refactor process at present by me and a few others.

Do the account managers for ES (non-billable) get paid for their time? If so, how does that $ flow?

hah. see above answer, we've historically done a poor job of resourcing account management. if it was to happen, they'd be included on the invoice sent to the client, or transferred internally once it was in my.enspiral (although haven't heard of this happening). instead i'd like to see us do something similar to the Enspiral Ops team, where consulting teams would have explicit financial agreements with an account management pod, for example 10% of revenue earned by the consulting team is immediately sent to the account management pod who sources work for the consulting team.

[fosterlynn]

@ahdinosaur thanks much! I'm working on the Enspiral sample data, slowly. Have some issues I need to think about and post.

i'd like to see us do something similar to the Enspiral Ops team, where consulting teams would have explicit financial agreements with an account management pod, for example 10% of revenue earned by the consulting team is immediately sent to the account management pod who sources work for the consulting team

None of my business, but just to note that another option is to pay out of the account income received based on actual hours the acct manager worked for the time period, and whatever formula you like. No right or wrong, just choices. VF will support either. NRP can figure this all out based on flows as far back in history as it needs to, and with whatever level of complexity, but we haven't figured out how to split off this logic into something easily callable.

[coopchange]

This is exciting. Commenting as affirmation for good work, and I look forward to re-reading all this and watching the video to contribute more fully.

Aside: That loomio discussion's crazy long, I wonder if Wezer was mentioned? Meeting a rep soon, I dunno if they've interfaced with y'all thru OVN or VF ... I imagine they've played with similar legal pain points and/or would benefit from the my.enspiral process

[bhaugen]

I did not see Wezer mentioned in Loomio. We've talked to them because the Mutual Aid Network uses them. But we have not used Wezer ourselves, other than a little light use in the MAN.

[dan-mi-sun]

Just checking in here to try to get more involved with the VF sprint to see how y'all define user journeys etc...

[dan-mi-sun]

@bhaugen I am wondering if you guys have a common framework or questionaire that you use to help to map out uses of a systems (such as the accounting proceedures of my.enspiral / cobudget / ES / ops team)

Or do you go out and mix it up inside the domain and then try to find domain experts and then question them this way?

What has worked well in your experience?

[bhaugen]

@dan-mi-sun so far,

• we have written use cases and examples of real-world situations first as plain text, then
• translated them into our emerging vocabulary, then
• translated them into json-LD, then
• drew diagrams in @elf-pavlik 's emerging diagramming style.

Most of them are in the use-cases directory of the main valueflows repository.

I hope I understand correctly what you mean by domain expert. If not, please correct me. So far, I have been the domain expert (somewhat faked although I have a lot of experience) in economic networks, Pavlik has been the domain expert in semantic web formats, @pmackay has been the domain expert in circular economy, @gcassel has been our domain expert in organizational form and social communication (although he might want to re-characterize himself...), and we hope to recruit some real experts in accounting in a couple of sessions that are going on this week.

For the enspiral domain, @ahdinosaur has brought some info, although I don't know if he would call himself an expert, and we've reposted some things written by Alanna and Jessie Kate, but we have not translated them. @fosterlynn and Mikey and I did a treatment of an Enspiral scenario very early in the development of Value Flows. It includes text and early-stage VF vocabulary, but not json-LD or elf-diagrams.

But if we were to dive seriously into future-my.enspiral, we would need to engage with people who are deep into using and understanding the current system. We don't have that willing collaboration partner yet. That is also why I offered to be part of the team: to learn the domain.

[elf-pavlik]

I missed this issue when originally created and still haven't caught up with this whole conversation. Just sharing quick thought:

1) I would call all accounts used for monetary currencies virtual (describing only physical things as 'real') 2) We can model virtual resources like monetary currencies in similar way as physical resources

• agents keep physical resources as stocks in particular locations
• agents keep virtual resources (currencies) as deposits on particular accounts
• different agents can own different amounts of particular physical resource from the same stock (at location)
• different agents can own different amounts of particular virtual resource (currency) from the same account

In short, Instead of trying to nest virtual accounts I would focus on what we want to capture and in this case it seems that we try to describe ownership shares of certain virtual resource (monetary currency) deposited on particular bank account (also virtual).

Another possible source of inspiration: https://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29

[fosterlynn]

@elf-pavlik interesting parallel with logical volumes, ha. And I like the idea of being able to treat physical resources in a similar way to money resources (allowing different ownership of parts of a stock in a location). Although the Enspiral use case probably doesn't have much in the way of physical resources.

Seems like it's time to see if the "underlying resource" concept will work here (referenced above in the thread, I think). I think each of the parts owned by a different person should be an Economic Resource in its own right. The whole bank account is an Economic Resource too though, and will have its own legal ownership. We have thought about creating a relationship between resources for "underlying resource". In this case the legal bank account would be the underlying resource for the individually owned piece of it.

(Another use for underlying resource is rental as a resource (rights to use), with underlying resource of the apartment or whatever.)

Caveat: We have thought about it for a while, but not implemented it.

[dan-mi-sun]

@bhaugen your unfolding of domain expert covers the bases I was thinking about (sorry, this is legacy jargon from computing training)... a more agile word might be 'product owner'? Dunno.

Anyway - I have started a new usecase which I am much more familiar with which I think collides with this one...

[bhaugen]

Here's to collisions!

[ahdinosaur]

In short, Instead of trying to nest virtual accounts I would focus on what we want to capture and in this case it seems that we try to describe ownership shares of certain virtual resource (monetary currency) deposited on particular bank account (also virtual).

just wondering, how would this approach handle multiple virtual accounts (checking, savings, etc) per agent within the same bank? since that's another use case here, but maybe could be solved as a tracking system rather than separate accounts.

[fosterlynn]

just wondering, how would this approach handle multiple virtual accounts (checking, savings, etc) per agent within the same bank?

I would think those are separate bank accounts, thus separate vf:Resources. The resource of a bank account has an identifier of the account number, plus the bank I guess (like routing number). So savings and checking different resources, and a virtual account would be a part of one of those. Does that work for how Enspiral does it?

[ahdinosaur]

I would think those are separate bank accounts, thus separate vf:Resources. The resource of a bank account has an identifier of the account number, plus the bank I guess (like routing number). So savings and checking different resources, and a virtual account would be a part of one of those. Does that work for how Enspiral does it?

in a very unimportant side-conversation, @agentlewis brought up the idea of having many virtual accounts for each agent, which still all are part of the same single bank account. but i think @elf-pavlik is right that virtual my.enspiral accounts underlying a single bank account is the same as many bank accounts underlying the actual resources (or lack thereof), so if the system can be fractal than it doesn't really matter what level you're at.

[elf-pavlik]

in a very unimportant side-conversation, @agentlewis brought up the idea of having many virtual accounts for each agent, which still all are part of the same single bank account.

I wonder about the use case for one agent having multiple 'virtual accounts' for monetary currency deposited on single bank account.

I also think we also need to first clarify Recording a vf:Transfer vs vf:Transportation

[bhaugen]

I wonder about the use case for one agent having multiple 'virtual accounts' for monetary currency deposited on single bank account.

Earmarked funds.

[elf-pavlik]

Earmarked funds

That sounds related to [hard vs soft allocation](hard vs soft allocations)

[danalexilewis]

earmarked funds

Is definitely one the use cases I was imagining.

Also being able to have distribution algorithms set up against specific virtual accounts would mean you could use them to manually distribute funds in a predefined way. Eg A revenue/profit share.

[danalexilewis]

Ge realising that you can define money in and money out accounts. And associate an account with a type of activity. Eg expenses, product a income and product b income.

[bhaugen]

We do that with value equations in NRP.