Well that's definitely a good puzzle. I've tried to model it for a bit, but it indeed looks like we'd need to add something to the language to make it possible at all! Thanks for bringing this up.

The rules listed (1,2,6,7 round down; 3,4,8,9 round up). AFAIK these are also the official Eurozone cash rules for countries that choose not to circulate 1 and 2 eurocent coins. (Altho of course, electronic transactions are exact to the penny.) So you might want to cover this use case.

I’m assuming there are guidelines as to when this conversion happens and how often. Must make itemized invoices lots of fun. Specially when you have returns or cancellations

That's a very good question. So the DSL here operates an agnostic source/dest transaction model, which is akin to the credit/debit model sans the semantic baggage. The goal of this model is indeed to be "tracking transactions" in the abstract sense, having the benefit of not forcing accounting decisions too early on when there is (still yet) none.

For example, if you create a transaction moving money from "@stripe:main" to "@acct:123" and "@acct:234", you're merely representing the fact that you want this money to be moved. Wether the movement is clearing off a liability or generating revenue is another concern that you (in our model) want to take care of in a separate layer, that will also likely involve some intense intentionality and iterations from your accounting team.

In a sense, it's as close to accounting than it is to warehousing money, moving unitary boxes of it from one location to another.

These two models have the same amount of information per entry, so they can actually be converted from one to another, enabling you to also represent some accounting-ish transactions with this DSL, e.g. with a send [USD/2 100] from @ar:invoices:1234 to @sales.

Nice! I've worked with a few similar real world payoff languages. This paper discusses one of them: https://www.infoq.com/presentations/haskell-barclays/

Yes exactly! There's actually two implementations, one tightly knit to our ledger product located at [1] and the new, standalone one (used by the playground) at [2]. In any case, in both implementations, the DSL is indeed MIT.

[1] https://github.com/formancehq/stack/tree/main/components/led...

[2] https://github.com/formancehq/numscript

It's indeed relative to cents in a sense, the idea is to force you to declare the precision of the monetary amount you're expressing.

You can see various interpretation of what "USD" means in the wild, as some APIs will happily parse USD 100 as $1.00 while some others might parse USD 100 as $100.00.

So we recommend this explicit [ASSET/SCALE AMOUNT] notation, where SCALE describes the negative power of ten to multiply the AMOUNT with to obtain the decimal value in the given ASSET.

It makes subsequent interaction with external systems much easier. You can read a bit more about it here [1].

[1] https://docs.formance.com/stack/unambiguous-monetary-notatio...

Hello, I'm one of the Numscript devs. The Numscript CLI does have a `numscript run` command, which is hidden for now but will be released in the following days. It behaves in the same way as the playground, and you can take a look at it with `numscript run --help` command

You might like https://martin.kleppmann.com/2011/03/07/accounting-for-compu... which shows it as a directed graph.

Yeah that's a good question, you'll want to leverage the `overdraft` functionality for that, enabling the account end balance to go below zero.

So you could do something like:

    send [USD/2 10000] (
      source = @my_bank:loans_made allowing unbounded overdraft
      destination = @my_bank:1234
    )

There's a little bit more to it if you want to create accounting-perfect entries, but a simple way to map src/dest to cr/dr entries is to say that every credit becomes a destination, and every debit becomes a source.

You can then consider debit normal accounts as having their debit balance being equivalent to the sum of entries where the account is source, their credit balance as the sum of entries where the account is destination—and do the opposite for credit normal accounts.

We've written a bit more about it here [1].

[1] https://docs.formance.com/ledger/advanced/accounting/credit-...

Thanks for the heads up! While the Numscript backend itself uses big.Int, we're still using normal javascript numbers in the playground for now so that's where it's coming from. But we should definitely switch to BigInt in the playground code though and that would solve the issue.

In cryptocurrency the decimals are often a range between 8 and 18 decimals, sometimes much larger. The solution is always to use strings, and have separate fields or data models that explain the precision. The amount of languages and libraries, for tradfi or anything, is so wide that actually trying to use something other than strings for passing data between systems and applications would be self destructive

It's only ambiguous if you let it be. The rest is just implementation details.

Not as of today!