Do you or your company need accounting software?
Well, there are plenty of SaaS products out there that you can give your data to, but maybe you also really like Django and would rather have a foundation to build your own accounting system exactly as your company or your product needs.
On this episode, we're diving into Django Ledger, created by Miguel Sanda, which can do just that.
This is Talk Python to Me, episode 502, recorded March 6, 2025.
Are you ready for your host, please?
You're listening
to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both accounts over at fosstodon.org, and keep up with the show and listen to over nine years of episodes at talkpython.fm.
If you want to be part of our live episodes, you can find the live streams over on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows.
This episode is sponsored by Auth0.
Auth0 is an easy to implement, adaptable authentication and authorization platform.
Think easy user login, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/Auth0.
Hey, Miguel. Welcome to Talk Python To Me.
Hey, thank you, Michael, for having me.
I'm excited to have you here.
I'm looking forward to talking about Django stuff.
Django is certainly one of the premier and one of the longest vibrant web frameworks from the Python community.
You've got a really interesting project that you've created here on Django Ledger.
So it's going to be a lot of fun to talk about it.
Yeah, absolutely.
Yeah, let's do it.
Now, before we dive into accounting and all of those things, let's first talk about you, your background.
I know it's a little bit specialized.
And actually, I think a little bit of your history really is kind of a case study of things that I say, like really help people do lots with software and Python.
So
yeah,
let's dive into it.
Yeah.
No, absolutely. So yeah, absolutely. This is Miguel Sanda. I'm the lead developer and the creator of Django Ledger. I have been working on that project for quite some time now. It has been going through several different iterations and the evolution is quite interesting. But as far as my professional background, I have about nine years of experience in the finance sector, specifically in the nuclear construction sector here in the United States. That was my beginnings in the finance sector. After that experience, I became a data scientist. So, and I joined one of the largest utilities in the United States as a data scientist to work on power distribution and generation analytics and engineering stuff for quite some time. So, I got about eight years there.
And from an educational background, I have a background in engineering and business. So, So, yeah, I know it's such a crazy thing.
I always say, you know, I went back into programming just because I wanted to make my hobby my career.
And here
I am.
So and about two years ago, me and my wife, we founded Edma Group, which is an accounting and financial planning firm.
It is focused on small business and real estate investors.
So we basically help them, you know, put together a plan for the business.
We take care of the bookkeeping, the accounting, and we work on all sort of financial-related stuff with them.
So, yeah, in a nutshell, that's what it is.
What a wild mix,
huh?
Yeah.
I was going to ask
you if it's stressful to work on accounting software, but then you mentioned nuclear.
Yes.
The consequences are way higher on nuclear than they are on accounting.
That's right, yeah.
So, yeah, I work on a lot of financials and stuff related to nuclear construction.
a lot of regulatory stuff there
going
on.
But yeah.
Oh, there's got to be.
Yeah.
There's got to be a crazy amount of regulation there.
Yeah.
It's
interesting, you know, especially when it comes from financial reporting standpoint, a lot of the, you know, financial gymnastics that had to happen in order to properly report financials in that sector, you know, it had to do a lot with, you know, understanding the nuclear side of things.
and the energy generation side of thing and also the accounting and finance side of things.
So it was a very interesting experience there.
Yeah, I'm sure it was.
Let's talk about nuclear just for a second.
So are you bullish on nuclear?
Do you think nuclear has an important role to play here?
To me, it's such a contradiction of trade-offs.
On one hand, we have to get rid of pumping carbon into the atmosphere
now.
You
know what I mean?
And there's no better option than nuclear, like not even close.
On the other hand, at least the way nuclear is done in the United States today, so much of the history comes from let's build these power plants that also generate plutonium for our nuclear weapon program.
And so they didn't make tradeoffs necessarily that were safer or would store the waste in a better, less dangerous way.
It was more about like, well, let's get this cool, really reactive thing that
comes off.
And I know there's a ton of work with Thorium and other things to make it kind of take a different path.
Yeah.
Right.
But I don't know how far we've taken that path.
How do you feel about nuclear?
Are you for or against it?
It
is a double-edged sword, you know.
I think nuclear, in principle, is a very clean source of energy if done properly, if done correctly, of course.
Obviously, the downside of that is, you know, you're dealing with something that could potentially be catastrophic if it's not controlled properly.
So, you know, working nuclear back in about 15 years ago, technology was very different.
So the new generation of plants were being built in China and the United States.
So they relied on a lot of many different mechanisms to kind of like control something like that.
Very different from the nuclear power plants that were built along, you know, about decades ago.
But I think from an energy source standpoint, it's very clean.
Obviously, it comes down to how well it is monitored and controlled to make sure that, you know, we don't end up being, you know, harming the environment or
human lives
or anything like that.
So I live nearby my home.
There's four nuclear power plants.
So
there's actually quite a few in the southeast. Yeah,
that's right. So, you know, you have that five mile radius, 15 mile radius. And these are the power plants that were built back in back in the 70s or a long time ago. So, yeah, I mean, like I said, it's a double S store. There's no right or wrong answer to that. But I feel like it's very reliable. And from a power distribution standpoint, it is always a good base load to have because it's kind of like that permanent, you know, like capacity that you have.
there. And then you have other things like pickers and stuff like that, you know, that come into play when demand goes up.
Yeah.
Yeah. I'd be all for it as soon as we have fail safe instead of fail explosive sort of things, you know, like
salt
reactors that like drain themselves rather than
overheat
and explode and so on. But
yeah, not that this is
a nuclear show, but I think it's just, you know, you're so close to it and it's such an
interesting,
we're
at such a decision point.
Yeah,
but I have
to say the new generation, my understanding is it's much smaller, it's safer, it's more of a controlled environment.
So, you know, my understanding is that they're doing good research and good, you know, advancements in that area.
But it's, like I said, it's been a while since I've been in nuclear, so I can't speak to that.
Yeah, I feel like there's a lot of regulation, a lot of old perceptions that are going to keep regulation super hard for it.
But yeah, let's talk
accounting.
Yeah, absolutely.
Let's talk accounting.
Switch years.
Yeah, for sure.
So for your project, I think maybe let's talk a little bit of just a tiny bit of the history of accounting, double entry accounting, these types of things.
All this stuff, this is not new technology in a sense.
It comes from 1494, some of these ideas here.
But people used to do it with paper.
And now you're building cool projects with Python and Django to do it.
Yeah.
So
I guess what did you use?
It sounds like you've done a ton of financial stuff.
What did you use at different stages in your career that weren't this?
What was the history that led up to your experience to build this?
Well,
yeah, absolutely.
So like I said, I started working in the accounting and finance sector.
But at some point, I started kind of like creating.
Me and my wife were also entrepreneurs.
So we started our own businesses.
And obviously, you know, when you're a data scientist and you know all this Python and I knew Django, I kind of wanted to start my own bookkeeping of my own businesses, you know, using Django.
Right. You know, I can do this thing on my own, you know.
So I started creating this project back in 2018, something like that.
The repo went live in 2020.
But it was my way of keeping my own books.
It was kind of like my journal.
I was just adding transactions to it, you know, looking at the back statement, keeping my own bookkeeping so I could do my own taxes and my own monitoring of my business.
So that's how it started. Right. And eventually it started growing and growing and growing.
And I added an interface and I created the Django views and things like that.
So and, you know, at some point I felt like it was mature enough to share it with the world.
So I posted it back and published it on GitHub back in 2020.
But it was very early stages.
You know, it was buggy.
It was by any means it wasn't ready for any production environment or anything like that.
But throughout the years, you know, I kind of dedicated some time to it until it grew to the point where, you know, it is today.
So and that is because, you know, I've dedicated, you know, a lot of time to it, a lot of research involved.
and yeah so it's been interesting so it's been quite a while it's not a small project by any means
no it's definitely not it's got a good mix of technology here got a decent number of contributors that's great a thousand get up stars so it's certainly got some momentum here that's fantastic are you using you said you're starting this you have started this independent firm to do bookkeeping and accounting for other companies Are you using this as part of it or is it still something you're using personally?
I use Django Ledger to, because there's different use cases of the software, right?
So it's not just bookkeeping for, you know, if you wanted to keep the books of a certain firm or a certain company, right?
The way I use it is I run simulations.
So basically what I do is, you know, if I have a client that needs some, we need to implement some sort of financial plan.
You know, I've had, you know, like what's called blueprints.
You know, in the software, you write something that is called blueprints that help you make, you know, like dispatch transactions and things like that.
So I use it to run simulations, basically, and present financial plans to small businesses and business owners and present them in a way that is obviously, you know, it's visually appealing and things like that.
But all the background is done in Django Ledger.
So that's one of the ways I use it, in addition to keeping the books of one of my businesses.
Nice.
Yeah, there's nothing like actually using it in production for real use cases that makes you realize something.
Well, maybe that's not perfect.
You're like, oh, no, that needs to change.
This isn't going to work, right?
You're really
running into
the real world quickly that way.
Yeah.
There are use cases for, you know, you could use Django Ledger, for instance, if you had a startup.
or you had something that requires you to keep the books updated, or if you wanted real-time analysis of how your business is going, Django Ledger is a good solution to that because you could, you know, one of the benefits of Django Ledger is to being intentional about financial transactions of your business, right?
So usually how it works is you have an application that has some sort of like a single entry database where you record transactions.
But those transactions, they do have a ripple effect, right?
They do have a ripple effect in the financial statements.
And usually a bookkeeper or an accountant needs to come in later and piece it all together, right, in order to produce financial statements or preparatory taxes or things like that.
But Django Ledger Bridges kind of like closes that gap.
It is intentional from the moment the transaction is created.
So you can always get financial statements pretty much on real time if you had a financially driven application that you'd like to use Django later for.
This portion of Talk Python to Me is brought to you by Auth0.
Do you struggle with authentication?
Sure, you can start with usernames and passwords.
But what about single sign-on, social auth, integration with AI agents?
It can quickly become a major time sink.
And rarely is authentication your core business.
It's just table stakes that you got to get right before you can move on to building your actual product.
That's why you should consider Auth0.
Auth0 is an easy to implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 different SDKs and quick starts, Auth0 scales with your product at every stage.
Auth0 lets you implement secure authentication and authorization for your preferred deployment environment.
You can use all of your favorite tools and frameworks, whether it's Flask, Django, FastAPI, or something else, to manage user logins, roles, and permissions.
Leave authentication to Auth0 so that you can start focusing on the features your users will love.
Auth0's latest innovation, Auth4Gen AI, which is now available in developer preview.
secure your agentic apps, and integrate with the Gen.AI ecosystem using features like user authentication for AI agents, token vault, async authorization, and FGA for RAG. So if you're a Python developer or data scientist looking for an easy and powerful way to secure your applications, get started now with up to 25,000 monthly active users for free at talkpython.fm/auth zero.
That's talkpython.fm/auth zero. The link is in your podcast player's show notes.
Thank you to Auth0 for supporting the show.
Yeah, I don't know that I've actually given you a chance to properly introduce it.
You know, how would you tell, you know, what's the elevator pitch for Django Ledger?
Someone, what projects do you work on?
Yeah, so, I mean, Django Ledger is, it's a financial framework, what I would say.
It's a financial framework on top of other frameworks.
So what I would say Django Ledger is it leverages Django as a framework, you know, all the security, everything you want to leverage, everything Django is famous for.
But on top of that, Django Ledger is the financial framework on top of Django.
So what you do is basically you don't have to figure out, you don't have to reinvent the wheel when it comes to, you know, the double entry accounting system, right?
What you do is, you know, if you had a team of developers and you had a team of accountants or finance people, you know, they can work right off the bat, right away using something like Django Ledger because there is a common interface for that, for both of those worlds to interact, right?
So Django Ledger saves a lot of time when it comes to developing a financially driven application that developers can use, you know, from a software development standpoint, you know, from an application logic standpoint.
But at the same time, it also helps accountants keep the financial behavior updated, you know, and it's all based on Python functions.
So which is pretty simple.
Yeah, that's really neat.
So the name here is, or the subtitle is Object-Oriented Accounting Engine.
So is Django Ledger a finished application or is it a library that I plug into my application?
You know, is it ready to go out of the box or is it a framework to build my accounting engine?
Yeah, it can be both.
You can use it out of the box as a very basic replacement for commercially available software.
I don't want to mention any of those, but you could go online and find accounting software.
You'll find those.
I've used a couple over the years.
I could
name them as well.
So the foundation is there.
You can go in there.
You can create transactions.
You can import your bank statements.
And so when I created Django Ledger, I wanted to provide some basic functionality from a UI standpoint so you can manage your finances.
But at the same time, you can use it as a library.
You can extend Django Ledger.
And to your point, it's object-oriented accounting engine because you can use the models inside Django Ledger to extend and adapt your business logic to the models.
So you can pretty much, you know, kind of like create your own little financial world.
Right.
So I'll give you an example.
So if you if you have if you're into real estate, for instance, you could kind of create take the ledger model, extend it and make it a rental property.
Or if you are in the, for instance, the farming business, you could create, you know, let's say, hey, this is my tractor.
Right.
Right, right. Or crops and commodities and all the details of commodity trading and pricing and all that, right?
That's
right. So Django Ledger is unopinionated when it comes to that particular aspect of the finance and accounting sector.
But you can extend it. Like I said, you can extend it and incorporate that domain-specific knowledge into the models and use the blueprints to dispatch things.
you know.
Okay, interesting. So that sounds like if I'm creating a Django application and it's going to have a core financial or accounting component to it, bringing Django Ledger in could really make that work well, right?
That is correct, yes. That can certainly help you with that.
So how does that work? I guess, what are my options? Would I expose a subset of my application as effectively a styled Django Ledger sub-application, like you kind of can with the admin backend and stuff like that?
Or would it be maybe I write my own UI and then I just work with the models and some of the libraries that come with Django Ledger?
Yes.
So if you have an existing application, you can pull in Django Ledger and pretty much, you know, if you're using Django, you could either grab a Django model and kind of create a relationship with a ledger model or on an entity model, right?
and integrate it that way.
So if you have an existing application, you can bring it in.
Or you could use Django Ledger as the total foundation of your application.
You could write APIs, you could write all the things that you need to kind of integrate with other things.
But you have plenty of options when it comes to bringing Django Ledger into your existing project or starting from scratch.
Okay.
What if I'm not doing Django?
So there's, you know, what if I'm doing Flask, for example, but I still want to use it, right?
You know, out in the audience, I've got a question, is it safe to run with Django Ninja?
And more broadly, could I expose Django Ledger as basically an HTTP endpoint, HTTP service, and then just do that instead of directly working with the model, have my app do its accounting over an internal API effectively?
Yeah, absolutely. I think one option if you're not using Django as part of your stack is probably to create a microservice or, you know, or some sort of like a gRPC server or something like that, that you could expose a function, you know, and deploy the service separated from your main application and just dispatch these blueprints that way.
Right. So you could just go through an API endpoint, you know, or something like that that can help you integrate with existing applications, even if you're not using Python, you know, or anything like that.
You know, like gRPC is really language agnostic and I've done it.
I've used Django Ledger with gRPC services to kind of like integrate it with with other things.
Right. So so you have everything that Python has to offer from a you have it at your disposal.
Sure. Of course. Yeah. And I mean, just because my mind is in that place of like, well, other Python frameworks.
So, yeah, you could use it with anything. Right. Because as long as it talks REST or it talks GRPC or whatever you want to expose it as. Right.
That's right. Yep.
Cool. Is there an API built into Django Ledger that we could already use, or do we integrate, do we just say, like, we're going to add the behaviors we need on top of it?
Yeah, Quarkly has a very basic API, and it's really being used to populate some of the charts that are, you know, part of the UI right now.
I just know
if you've got, like, maybe a JavaScript callback, it can get the data that way?
Yes, it has a very basic, again, it has the, not to get nerdy here, but it has an income statement call.
It has a, or a P&L balance sheet.
It has a very basic API where you can request that financial data and it's parametized.
So you can get it into your JavaScript world and kind of populate chart with, you know, with anything you want to use, like Chart.js or, you know, or if you're using any other stack.
So it does have some APIs built in, but it's not a full-blown API, you know, with, you know, like a gradual thing.
Yeah, yeah.
You know, honestly, that sounds good to me.
So often I'll see frameworks or I'll see things like this.
I'll say, well, it has a complete API.
And the complete API, what that means, especially with some of these, like, we'll add API features to your app.
It's just we'll let people query the database directly, right?
You know, like, oh, you can just hit this endpoint and that's that table.
And you put the query string as like the filter or whatever.
And just, I don't know, that's never, that's always felt like a cop out to me.
Because whoever's running the application or building and controlling the application should have some say of like, well, what are the actions you need to take here?
And this action actually involves three tables, not just one.
And it actually might also involve a transaction, right?
Which accounting is so often the most common example of why we need transactions and concurrency safety and all those things, right?
Yeah.
So having that greater control, like, you know, let's suppose we're back to our farmer, right?
Like record the sale of some commodity or something, right?
That might require multiple interactions.
And you don't want to depend upon somebody calling the right APIs against your sort of generic database as an endpoint thing, right?
That's right.
So one of the things that Django Ledger has is this concept of financial middleware.
So basically, there are separate stages.
When you make a call from Django Ledger into the database, you're not pulling the raw Django model out of the database, right?
The data is stored into separate different models.
One of them is a transaction model, which stores, you know, kind of like it's like your account, your account, your financial account and the money that gets allocated via credit or a debit.
But that is a very long form table.
Just pulling transactions out of that table is not going to give you the answer.
So basically, Django Ledger has different ledgers.
Number one is aggregating the data, you know, or pushing as much work as possible to the database layer to aggregate those transactions.
Right.
So let the do database do what it's supposed to do, right?
So it aggregates to pull the minimum amount of data into the Python memory.
And then there is another step, more steps there.
There's aggregation going on.
There's also accounting rules being applied.
There's a financial middleware that applies, you know, all sorts of things.
And then, which is called the digest process.
And then once you pull that out, you will get a Python object, which is an IOContext object.
And that has all the data you need, like already sorted out.
Everything is organized by account, everything.
And at that point, that is the object that you can use for if you're developing APIs or you're making a gRPC call or whatever.
So that's why, you know, in the context of Django Ledger, you don't go directly to the table because that is not efficient.
So Django Ledger is solving a lot of those problems for you because it's aggregating the data in a nice way so you can take it from there and integrate it into your application.
Yeah.
And that's exactly the kind of stuff I was thinking, right?
You lose a lot of the value of the application if you just go straight to the database.
That's right.
And honestly, what Django Ledger is doing is applying those accounting rules.
So you have kind of like a gap, let's call it gap compliant output, general accounting principle rules that are kind of like the best practices.
So from that point going forward, you can share it with the world pretty much.
Nice.
Okay.
So I guess back to the original question, Django Ninja would be fine to use?
Yeah.
Or Django REST framework, maybe?
Django REST framework, Django Ninja, you could use, I've used even GraphQL frameworks.
So if you can define your schema and you can do code first or schema first, whichever you prefer, I feel like the ones that are code first will give you that GraphQL schema right off the bat.
So you could use, I can't remember your name, but I think it's Ariadne or, there's two Django frameworks that are GraphQL.
So I've used both of them and there's plenty of them, but you can integrate any API.
gRPC, GraphQL, REST framework.
Message pack, you name it, right?
You can do
whatever
you want, right?
Whatever
you want, pretty much.
Okay.
Is there a database backend limitation or is there a database backend that you recommend?
It sounds like the more you ask the database to do, the more that might restrict which databases will actually work.
It's not just straight CRUD, you know?
Yeah.
So I would say, since it's based on Django, so whatever database Django supports should be okay.
I have used PostgreSQL for most of my projects.
PostgreSQL works extremely well.
Even on development, you use SQLite, and it works extremely well as well.
So I would try to avoid small databases for kind of like bigger project with a higher volume of transactions.
But, you know, it would really depend on, you know, how busy your application is.
Yeah.
I imagine a lot of them probably are not too busy, but you never know, right?
It depends what it's doing, I suppose.
Yeah, it depends on the use case, right?
So let's just say that you have a very traditional use case where you have a startup and you're developing your own application and you kind of want to have some sort of like a financial back end to it.
I think in those particular cases, it shouldn't be an issue.
I mean, whatever database.
You
could run that on whatever.
Because if you have a startup and you need to scale the recording of your purchases, you've got a good startup.
I mean, it's not going to be a startup for long if it's like we can't handle the amount of sales per second in terms of recording them, right?
Like, you know, good problem to have.
But it's not like scaling
your front end where people are like, you know, AI-ing cat pictures.
That's right.
I think a volume of 1,000 transactions, 2,000 transactions per day, you know, it's still relatively small compared to, you know, if you're using something like IoT or where you have billions and billions of records.
So I think
for
most financial use cases, you should be fine in terms of the volume of transactions.
Yeah, I would imagine just
something with a database that's got a good durability story, then you should be fine.
That's correct, yeah.
And certainly Postgres is incredibly well-known, incredibly well-respected.
You can get it as a service at so many, pretty much wherever you are, you can get Postgres as a service.
Yeah.
So one interesting idea that I have for the future of this project is see if I could integrate this with a distributed system.
You know, being a data scientist, I've worked a lot with Adub and Spark, you know, and things like that.
So I wonder if there's a possibility to, you know, if you're supporting, of course, more enterprise-y kind of like use cases to see if, you know, in order to have not a single point of failure, you know, if you could leverage, you know, distributed clusters, you know, or things like that.
But that's still, you know, experimental at this point.
Yeah.
How's it going?
Are you making it happen?
I have some ideas.
You know, I have a Hadoop cluster here at home.
So every now and then I
just
try to see if I could start developing some sort of like a Hadoop application that could support.
Because one of the things about Django Ledger is if you see the models, you have the entity model, the company model, then it goes down to the ledger model, then the journal entry, and then the transaction.
The ledger is a self-contained unit of accounting, right?
So the ledger itself is really a small piece of the company.
It's really a small piece.
The ledger could be like a car.
It could be like a tractor.
It could be even a cow, if you want.
So whenever this ledger model kind of like runs the financial statement, it's really a small piece of the puzzle.
But even that little ledger, it is like a small company.
So basically, the ledger can compute the financial information anywhere. You could use something like salary, you could use something like anything like that, and then bring all the ledgers together and aggregate them, and you will get to the same answer.
So even if you're reaching a point where the database becomes an issue, you know, as far as from the data volume standpoint, you can piecemeal the call and you can break it, chunk it down and then aggregate it in separate, let's just say separate servers and then bring it back together.
Yeah, that's a really cool idea. You know, I think, did Django just add some background task stuff? I know this thing I pulled up as an external library, but I feel like that's something that's come into Django recently.
Yeah, I think so. I haven't really deep dived into this. I
use Celery.
I use Celery most of the time. You know, one of the things that I've included in Django Ledger is a very comprehensive kind of like list of signals that you could wire your application to. And if you had some sort of like a background task, you know, you could perform those things, you know, so you don't have to implement your own signals and things like that.
Oh yeah, that's nice. This portion of Talk By Thundering is also brought to you by Auth0. Earlier, I told you about how Auth0 can allow you to quickly get full-featured authentication built into your app so you can focus on building core elements. Now, let's talk AI. No, not using AI to integrate Auth0, though that probably worked pretty well. I want to tell you about Auth0's latest innovation, Auth4Gen AI, which is now available in developer preview.
You can enable AI agents to securely access tools, workflows, and data with fine-grained control in just a few lines of code.
Why might your agents need auth?
Well, here's a few reasons.
User authentication.
You can easily implement secure login experiences for AI agents from interactive chatbots to background workers.
You also get the token vault.
You can use secure standards to retrieve and store API tokens for Google, GitHub, and many other APIs.
You get async authorization. You can let your autonomous async agents do work in the background and access the logins that they need. And finally, FGA for RAG. Auth0 allows you to only retrieve documents users have access to, which means you avoid leaking data through your AI. So if you're a Python developer or data scientist looking to build AI-driven apps, get started now with up to 25,000 monthly active users for free at talkpython.fm/Auth0. That's talkpython.fm/Auth0.
The link is in your podcast player's show notes.
Thank you so much to Auth0 for supporting the show.
So we were talking about different databases.
What about MongoDB just released the Django MongoDB backend.
Could you use something like that, you think?
I think so.
I mean, if it is official and if it supports the Django ORM, I think if it's...
It does, yeah.
I don't see any issue with that.
Because again, all I did was to layer the financial aspect of things on top of Django.
So my starting point is, hey, anything that you could use with Django, you could use with Django Ledger.
I
mean, it's really that simple.
It's pretty early days.
I'm not sure I would recommend it.
However, I'm a big fan of manga.
And it's just interesting that it's there.
But I don't know.
For these kinds of things, I might actually stick with.
It might be interesting to test it out.
I mean, I might take that as a to-do item and see how that turns out.
Yeah,
I'll leave the link to this new Django backend for Mongo.
It
comes from MongoDB.
The people, you know, they spend a lot of time building it out.
It's not just some random project that somebody came up with.
Yeah.
So I want to dive into the technical bits and some of the moving parts.
This ledger idea is really interesting and seeing how that fits, It's almost like you could have subdivisions in your company or divisions within your company, right?
Like here's the part that deals with the farm, but we also have like a wine and fruit stand at the front.
Maybe we'll have a separate one for that so we can treat them differently, but we want to see them as also together in the same system.
You want to maybe talk about how you model those kinds of things?
Yeah, absolutely.
So Django Ledger has different ways of kind of like pull data out of the database and to kind of like structure a business in a way that you could get financial reports by departments or by business sections or whatever.
So one of them is the entity unit model, what I call the entity unit model.
And it's basically when you create journal entries, you assign that unit to that journal entry, right?
Not you as a – you don't have to do it manually, but since the blueprints will do most of that for you.
But the Angular has this capability of chunking down your reporting into separate reports that aggregated together, obviously will give you kind of like the parent balance sheet or the parent income statement, right?
So you could leverage the units.
It's called the entity unit to divide your business operations.
To your point, Michael, it's like if you have your lemonade stand here and then you have a separate side where it deals with a separate office on a different location, you could leverage those units and logically separate the transactions so you could pull reports for specific units as well.
So it gives you a lot of flexibility when it comes to reporting and to keeping your data nice and clean, so separated and segregated.
Yeah, that's super neat.
Could I generate reports?
Let me rephrase that.
Will it, without me writing any code, will it generate reports that I could give to an accountant to say, here's our monthly transactions and purchases and go do our bookkeeping with this.
I know some of them are like, well, just use QuickBooks and then we'll share the QuickBooks thing.
It's like, well, I don't want to use QuickBooks.
Yeah, I want something cooler.
So anyway, yes, answer to your question, yes.
There is a PDF format.
There is PDF format support.
So basically when you pull a financial statement, when you ask for a balance sheet in Django Ledger, in the management UI, you will have a button there that you would click and it will literally create a PDF for you to print and share
however you like.
Yeah, nice.
What about
CSV or Excel? I feel like that's probably the primary. That's the JSON of accounting world.
That's right. I mean, I think that feature right now, it's not implemented.
It would, you know, pull request welcome.
I was going to say, PR is welcome.
You are welcome. Absolutely. Yeah. But, you know, I don't think it would be too hard to implement because, like I said, you know, once you digest, when you call that digest function, which is part of the IO mixing side of things, you know, if you go into the repo, you guys who want to see the code, you know, if you go to the IO mixing and the IO, yeah, you can just go there.
But, you know, the output of the digest process is just a Python dictionary.
So at that point, you know, we could just use pandas or polars, you know, or something like that to kind of like save it on a CSV.
Oh, yeah.
I hadn't really thought about the pandas or polars side of things.
Yeah.
That makes sense.
Yeah.
So you could use Jupyter Notebook as well to integrate with this.
I use it a lot.
That's a cool idea.
Yeah.
I guess you could have a whole suite of notebooks that kind
of do
the live reporting and stuff.
And then once you get
into the pandas
and polars, you can start talking about Dash and other dashboard types of things if you really, really wanted it.
Yeah, yeah.
All you need to do is set up your notebook to work with Django.
And once you do Django, that's set up, you can leverage everything in the Jupyter notebook.
As a data scientist, you could use HoloViews.
You could use any
plotting library you want.
So I have a different angle of a question for integrations that comes from the audience, from Joe.
Joe asked, will it work with Wagtail?
Are you familiar with Wagtail?
Yeah, the CMS.
Yeah, probably the most popular Jingo CMS, which is cool.
Do you know?
Do you have any idea?
I mean, I've certainly not tried to integrate.
I've not tried to integrate with Wagtail.
I use Wagtail for some websites that I've built.
Understand, you know, the Wagtail.
Again, it's a Django application, right?
So
probably, right?
I mean, if you're extending and customizing Wagtail, you probably could.
So if you create a page, because I'm familiar with how Wagtail works.
So basically, in my mind, I'm kind of like replicating what I would do is basically I would create a page in Wagtail, you know, that page model, right?
And my understanding is that there's a section where you could create your context.
You can get your context for your page.
And at that point, you could bring in Django Ledger and the digest function where you could just get that big Python dictionary and you're going to have all the financial information there and you could just throw it to your template and just populate whatever you want to populate in that website.
So, yeah, I mean, I don't see any reason why you wouldn't be able to integrate it with Wagtail or something like that.
Yeah, interesting.
You know, the world is looking for an alternative to WordPress these days.
WordPress has gone crazy.
I don't know if you've been following the drama
I'm not I'm way
too deep
into finances right now
There's some interesting financial aspects but I don't want to go into it it's a whole different community but basically the main owner of WordPress started demanding a bunch of money from companies that were using it even though it was open source
it
really spooked a lot of people who were really invested in WordPress so looking for alternatives like Wagtail I think it's something that's happening more
than it did
last year.
And to piggyback off of a little bit of the WordPress concept of this plugin, we know there's a lot of plugins that are being created in WordPress.
Django Ledger can also work as that foundational kind of like WordPress-like platform where you can bring in via Django app a plugin.
One example that I'm working on right now is to perform like bank reconciliations, for instance. Bank reconciliations is not something, it is an accounting process. It's not built into Django Ledger itself because that would be, again, I don't want to be opinionated as to what needs to happen from an accounting standpoint. But a bank reconciliation, it's something that I'm creating as a separate Django application. So it wires
and it looks at each line and goes, what is this and how does that apply and do I need to save it into
this
or not?
Is that what we're talking about?
Well,
bank reconciliation is you take your bank statement, which has transactions on it, and then you have the transactions that are staged because Django Ledger has a staging area where you bring in your transactions and then you kind of map them and once you click the button, it will go into the actual transaction database.
And there's a couple other controls that, you know, from a posting standpoint, and whether or not it hits the books or not, other controls are built in.
But a recon, a financial bank reconciliation, is make sure that the transactions that are in your bank statement match the transactions that are in your database.
And the starting balance and the end balance match whatever is in your bank, right?
So it
is a regular process.
us accountants we do to make sure that our data is accurate.
Right.
Because if you got more money, there's something that wasn't recorded.
If you got less
money, there's maybe an expense or something that wasn't recorded, right?
That's right.
And that can be implemented via plugging.
Going back to the original point, you can create a Django application that does recons.
It's called ReconSuite Recoms.
And just add that functionality to Django Ledger.
Yeah, that's cool.
Yep.
So you
said bank statements.
I
imagine a lot of digital companies these days, and even some that are not, probably have Stripe or Square or something like that as well.
And the way that appears on your bank account is like blobs, right?
So when you have a bunch of sales, say, through Stripe, Stripe can pay you daily with a couple of days delay.
And it says today you get this much money.
But then you've got to go to Stripe to actually see the
details that
would map over to Django Ledger, right?
That's right.
But, you know, Stripe has this API that you would integrate with.
I'm sure that, you know, you could get the detail and get those transactions into your staging area and then visually looking at them and just pushing the button and integrating those
into your Django Ledger
systems, right?
A fun in quotes thing you could do is you could actually hook up to the Stripe webhook notifications
and
drive those straight into records in Django Ledger, right?
Yeah, absolutely.
I can see that happening.
Python is such a diverse ecosystem.
You can do pretty much anything.
Yeah, that's right.
I did that on a project not too long ago.
It's both easy and really hard because you get so much data from Stripe and the scenarios and what it means and stuff.
It's
kind of hard to
decipher.
But hooking into that data flow of a transaction happened, something was refunded or whatever.
It's pretty
straightforward.
So it sounds like that might be a cool plugin, actually.
It
might be a cool plugin.
There's many different plugins that we can create for Django Ledger.
Again, Django Ledger is just a foundation.
It implements a double entry accounting system.
It's not an automation framework.
It doesn't automate a lot of these things.
Those could be done via plugins, and the community could certainly contribute to those things.
Yeah, yeah, they could.
So let's talk licensing.
Over here I see, well, it's like stuck at the top, which is kind of cool, that it's GPL 3.0.
So that is a copy left license, right?
So that means if someone builds an application on top of this and they distribute it, that means it's open source, right?
Yes.
As
a requirement.
But if they build on top of this and it's just a private internal thing that powers their accounting or something along those lines, then it doesn't have to be distributed open source.
Am I understanding that correctly?
I always get slightly off on my thing.
I think so.
I mean, the reasoning behind the GPL version 3 license is that there's a ton of work behind Django Ledger.
Django Ledger is, there's a lot of domain-specific experience that I've incorporated into Django Ledger for the benefit of the Python community, right?
So, you know, just like WordPress, WordPress has exactly the same license, you know, and look at what's become, right?
You know, WordPress is, aside from all the things that may be happening right now, but, you know, it became the foundation for blogging and for content distribution.
And people and developers were able to develop these plugins, going back to the plugin, you know, topic to extend WordPress, right?
So my concept with Django Ledger is about the same thing.
It's like, let's keep it open and let's make sure that we keep it open.
Anything that is developed on top of Django Ledger is transparent because ultimately it's important that finances are not a black box.
It shouldn't be a black box, right?
And for most developers and accountants out there who work with existing platforms, this data is on private servers.
We don't know what it is.
Obviously, they have their own policies and their privacy policies and things like that.
But one of the benefits of Django Ledger is that it is open source.
You could use your own database, right?
So you can keep your data private.
You can control your own data.
But at the same time, you can extend it, right?
So all that functionality, I feel like it's really important to keep it open and that there's no bad actors out there who want to leverage something like this and kind of like do something that is not supposed to be, you know, not ethical or anything like that.
So, but yeah, I think that's, that was my, the main reason behind the licensing, you know, just to make sure that it stays open and that
if you want to use
it for your own commercial purposes, you know, if you distribute it, you need to keep it open.
You can use it on your own server as a software, as a service, you know, you don't have to distribute that.
But yeah, so that
was it.
Cool.
That's my understanding as well.
If you wanted to have it as a backend for something, that's totally fine.
But if you wanted to, Basically, if you want to distribute your software built on this, it has to be.
That's right.
Your software
has to be open source and
GPL3.
Otherwise, not so much.
That's pretty cool.
So another thing, obviously, listeners of this show are spread throughout the world, not just the United States.
And Joe out in the audience asked, basically, can this be used outside the U.S.?
Does it only work with the United States tax structures?
Does it have the dollar sign hard-coded?
Is it going to do multiple currencies?
currency transfer conversions, that kind of thing.
So, again, the framework itself is unopinionated.
So, yes, you can change the dollar sign to whatever you need to change.
It's actually a Django setting. So you can change it in the settings.
That would be like your base currency? So if you wanted to do and say euros or whatever, but
then
maybe convert from dollars to euros because you want to think in euros?
It's literally a character.
You change
the character, and instead of a dollar sign, it will show a euro sign or whatever currency.
But everything is based on the Django decimal field.
So the decimal field, it is a two-digit precision decimal field, and it literally can be any currency.
And to answer the question about tax, Django Ledger doesn't do anything from a tax perspective.
It's not going to, hey, here's your tax return.
However, however.
Could you imagine how hard that
would be to write?
You know, I'll be honest with you.
I mean, if you understand the tax code of your country, mapping the, again, the digest function, that big dictionary you get back with everything aggregated and nicely done, you could map these accounts to a specific tax line and then do aggregations from there.
I see. Okay.
So, you know, when people talk about tax, you know, is this a tax-ready software?
Really what you're doing is how do you map a financial statement, each line, into a specific tax line for that specific country, which obviously requires knowledge and domain knowledge of the tax
code for that particular country.
Yeah.
Sorry, I just derailed you on talking about multi-currency.
And multi-currency, out of the box, it does not support multi-currency.
It doesn't mean it can't.
I've been kind of like visualizing how to implement multiple currency in an efficient way.
It's not that it cannot be implemented.
It just has to be efficient, right?
And the problem with multi-currency is that it is a very dynamic and it's a living embrace.
once you make it multi-currency, you basically make it a living and breathing system.
Why?
Because currencies value change
pretty much every day.
Every day.
So what that means is that basically if the rate of exchange changes, now you have some pressure to alleviate from the system, right?
So, and that needs to be alleviated through what is called like a reconciliation account, you know, in the accounting terms.
So you can alleviate that pressure in the P&L So everything is kind of like, everything is, it matches the way it should.
So, yeah.
Just to give people a sense of like how brutal it can be, even for simple stuff that I do.
So if I, I did something where somebody paid me with an invoice and I want to record how much income I got, do I record how much it is in your, like, let's say they're paying euros and I'm getting paid.
It's getting converted to dollars.
Do I, do I write down how much the currency conversion is when I send the invoice?
When they pay it, which goes through Stripe, but then Stripe doesn't credit me that or actually process it for some period of time after that.
Maybe who knows how much longer is it until the day that I get the payout and it's final.
But there's so many steps that are out of my, that you can't see, you have no visibility into.
Well, when in the day did Stripe actually finally reconcile that current conversion from euros to dollars?
And if there was some swing, then stuff doesn't match anymore.
It's really hard.
It is hard.
I mean, I'm sure we can figure something out.
That's not a problem.
I mean, it's not a matter of hard or not.
I think from a Django Ledger standpoint, you know, my concern is to make it as efficient as possible.
And yeah, and there's other accounting things that, you know, you have to incorporate.
You know, like to your point, you know, the invoice was written a certain date and then it was paid at a different date.
Then you need to record kind of like the rate of exchange on a daily basis.
So you can kind of like alleviate the system on a daily basis and record that kind of like reconciliation transaction because of rate of exchange changes.
So you just take it to a different level.
And at that point, I feel like it's going to get interesting.
That's for sure.
Yeah.
Yes, it
will.
All right, two final things that I want to touch on before we close this out.
One, security.
Like, what's the security story?
It sounds like you're probably leveraging a lot of the Django capabilities for security.
That is correct.
Yeah, and out of the box, it will use the regular Django Ledger security framework, authorization framework.
But if you can use, you can use all off.
You can use, you know, any of the frameworks out there that integrate with Django, you can, you know.
The permissions are different in Django Ledger because I wanted to enforce permissions at the database layer.
Not that they're not implemented at the database layer with regular Django auth, but there is a separate table that defines managers and owners of the entities and the companies that are inside Django Ledger.
Since it is a multi-tenant system, basically you can have, you know, like you could pretty much run an accounting firm, for instance, and you have clients that own certain entities and then the accountant, which owns the entity, can see all the companies.
Whenever you pull a query set from Django, you have to pass in the user model, right? And that user model is filtering at the database layer, the objects a specific request from a specific user can see and have access to. So I wanted to make it very, you know, very hard for you to show financial data to something or someone that was not supposed to see that data.
Yeah, that's really cool.
Maybe
someone has permissions to enter transactions, but not see all transactions or something like that.
Yeah,
that's right.
Yeah, that's a different level of trust to say.
Yeah.
Give you all of our sales versus you can record things.
Okay, and then let's close it out with roadmap. What's the future look like? Where are you going with this thing?
Well, my initial, so where I want to go first is Django Ledger has been around for a long time.
So there's a lot of things that I've done in the past that I would have wanted to kind of like do it in a different way.
So if you see the latest commits, it's just me trying to refactor the code so it's more clear and it's more maintainable long term.
So as the project evolves, what I want to do is start adding more controls, you know, and more things that are useful from a developer standpoint to integrate with other tools, right?
We talked about APIs.
We talked about all the other things, right?
So as far, you know, to answer a question, the roadmap right now is unclear.
So it's unclear not because I don't know what to do, but it is going to be based on customer feedback or developer feedback.
So one of the things that I want to compile is, you know, what developers want.
So from a functionality standpoint, so I can incorporate those features into Django Legend.
As a base account system, it's pretty stable.
From a UI standpoint, I know it could be prettier, but it's not meant to be a full-blown – it's not a drop-in replacement for commercially available software.
It's meant to be a management UI system.
So, yeah, I think, you know, going back to what is the roadmap?
There is a post on my website that I laid out, you know, a couple of things that can be implemented within Django Ledger.
And one of them is actually the multi-currency, the multi-currency support.
Right, right.
So I think that's one of those big items that can definitely be implemented in the short term.
Testing and coverage, that's another thing.
More testing, developers who want to add tests, unit tests into the software.
Those are important.
One thing to point out is that I am the only developer, not the only, but for pretty much 99% of the code has been written by myself.
I've written the code.
So the project is too big.
I can't focus on all different aspects at the same time.
So any developer out there who wants to collaborate and wants to throw a PR, PRs are very welcome
to make it more stable.
Do you have somewhere that talks about the plugin concept and how to extend it?
Because, you know, one of those challenges I know many, many people have is they want to add something to some large existing piece of code that's been around for a while.
And it's like, there's a lot to learn.
There's a lot to deal with.
And if you're like, well, you implement these three functions and you do this thing, you know what I mean?
And that's a much lower barrier to entry.
Yeah.
So, again, so one of the things that my objective is to make it more developer friendly because it's the finance and accounting domain sometimes is, again, it's two different brains.
It's two different brains into one project.
Yeah.
And, you know, if you're, if you, and it's a cool project because if you are a programmer, right, you will somehow have to learn accounting or some accounting in order to be a contributor to the project.
And if you're an accountant, somehow you would need to learn some Python, you know, to be a contributor to the project.
So one of the challenges with Django Ledger is not only you need to know Django, but also you need to have some sort of financial interest, let's just say,
interest to
collaborate to the project.
So, yeah, I mean, it's, you know, one of the challenges that I've had throughout the years is finding collaborators to the project, right?
And that's one of the reasons why Django Ledger, the development has been somehow slow, is because it's mostly my time who is being put into this project.
You should go on a podcast to get some awareness for it.
Yeah, let's do it.
Well, I think there's actually going to be a decent amount of interest.
There's a lot of people out there who are developers, but they've got to work on accounting systems.
They're like, well, I don't know enough to build one from scratch, but maybe contribute to one.
But PRs are welcome and
contributors are welcome.
100%, please.
I also noticed you have a Discord community and a Getting Started Guide.
Yes.
Yeah.
So the
Discord, I'm on the Discord so you guys can ask questions.
You know, anybody who wants to report a bug or has some ideas on Django Ledger, you can definitely join the Discord.
The Get Started Guide, it is a developer-focused guide that I put together for developers to get familiar with, to bring them in, somehow get their feet wet into accounting from a developer perspective.
So there's some table, there's some concepts there that I try to explain from a developer standpoint.
So it's not too daunting.
So it's not too intimidating.
So
that's a good resource to have.
All right.
Excellent.
I'll put links to those in the show notes.
Well, thanks for being on the show.
Congrats on the project.
It looks really cool.
Well, thank you for having me, Michael.
It was fun.
Yeah.
Yeah, it sure was.
See you later.
See ya.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Auth0.
Auth0 is an easy to implement, adaptable authentication and authorization platform.
Think easy user logins, social sign-on, multi-factor authentication, and robust role-based access control.
With over 30 SDKs and quick starts, Auth0 scales with your product at every stage.
Get 25,000 monthly active users for free at talkpython.fm/Auth0.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, Be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.