Once an Accounts system is set up, you use it by creating transactions and by querying the attributes of accounts. Transactions can come from other systems (like a system that gets purchase orders electronically), can be created by program control (like a check-writer for an accounts payable system or a payroll system), or can be created by a user filling out an input screen. Queries can be from a simple GUI tool, from reports such as bank statements or monthly reports of sales, or from programs that are creating transactions, like a check-writer that uses a querie to decide how large a check to write. All normal interaction with an Accounts system by creating transactions and querying attributes. The only exception is adding or changing the definition of transactions, accounts, or attributes, but that is considered a form of programming.
You can design a new Accounts system entirely by direct manipulation and by writing formulas on the same level as spreadsheet formulas. You start by defining the accounts and transactions that your system has. While most accounts are atomic, some of them are composite accounts made up of other accounts. For example, an inventory journal is a composite account made up of inventory accounts. (Or perhaps it is made up of departments, which are composite accounts that are made up of inventory accounts.) The most common composite accounts are those like journals, in which all their components are similar, distinguished primarily by name. However, some composite accounts can have every component different from every other. Usually the top-level of an organization is represented by an account like this, whose components will be the inventory journal, accounts payable journal, accounts receivable journal, payroll, bank account, and so on.
You define the fields of each transaction and the type of each fields. Some fields are multivalue. For example, an invoice can have a list of items on it, and each item has an inventory ID, a price, and a quantity. The "inventory", "price" and "quantity" fields are multivalues.
You define the attributes of each account. Some attributes are simply totals of a particular field of the transactions posted to that account. Others are month-to-date or year-to-date versions of another attribute. Others are arithmetic functions of other attributes. For example, on-hand for an inventory account is total purchases - total sales - total shrinkage. A composite account can define an attribute to be a function of the attributes of its component accounts, but an atomic account can only define new attributes in terms of its own attributes.
You define how an account handles transactions that are posted to it. In fact, most accounts have only one way of handling transactions, so there is nothing to define. An atomic account handles transactions by putting them on its list of transactions in order of their date. A composite account like an inventory journal just finds a component to handle the transaction and forwards it. However, a few composite accounts are different. The top-level account must handle a transaction be sending it to several of its components, usually splitting the transaction into smaller transactions in the process. For example, a sales transactions might effect several inventory accounts (if several items were sold at once), the sales account, and an accounts payable account (if the customer had a charge account with the store). You specify how this kind of account handles transactions by drawing a picture showing which components handle which kinds of transactions, and a picture for each transaction showing how the complex transaction is broken into simpler ones that are then forwarded.
A constant in any business system is change. Note only is data changing, but the business rules are changing. In Accounts, the business rules are encoded in the formulas used to compute an attribute, the fields in a transaction, the kinds of transactions or accounts, the relationships between accounts, and the ways complex transactions are broken into simpler ones. All of these things can be changed, but changing them is like changing the programs used in a traditional system, and so you have to be careful who makes those changes. Accounts makes sure that the changes are safe in the sense that it will not let you make changes that cause run-time errors. If you define a new attribute that needs a new field in the transactions then it forces you to define that field, too.
Accounts handles schema migration in the sense that you can change the definition of a transaction or an account. These definitions take place at a particular point in time. Transactions with an effective date before the transaction definition is changed will use the old definition, while those with an effective date that is afterwards will use the new definition.
Accounts makes it every easy to build a distributed system. Different accounts can be on different machines. It easily handles networks disconnecting and reconnecting, and machines crashing. At least, the normal operation of Accounts handles this easily. We are still figuring out how to handle schema changed, i.e. programming, in a distributed system.
Accounts is currently only a research prototype, and many of the features I have described are not yet implemented. In particular, although it has a system for creating input screens for transactions, it does not have support for reports or for creating transactions automatically (e.g. checkwriting). Accounts is written in VisualWorks, so you can always code these up yourself, but it really needs tools to do it without programming.
Accounts doesn't support changing business rules very well yet. Although it stores all the business rules in a database, it doesn't keep track of how they change over time. I know how to do this, though.
Accounts only runs on a single machine, and is currently not hooked up to a database. No major breakthroughs are required to make it distributed and to store transactions in a relational database.
On the other hand, we have built a direct manipulation system for defining accounts, transactions, attributes, and the relationships between them. You can define an entire accounting system without programming.
I wrote some patterns about Transactions and Accounts that explain why I think that Accounts will make month-end closing much easier than it is in most businesses.
Paul Keefer wrote a MS thesis on Accounts.