Guides for communicating with business accounting systems

[Ben Finney]

Howdy all,

What material should a team of programmers read before designing a
database model and export format for sending commerce transactions to a
business accounting system?

I'm especially not wanting ad hoc advice in this thread; this is surely
an old, complex problem with a lot of ground already covered. Primers on
pitfalls to avoid and non-obvious best practices are what I'd like to be
directed toward.

Constraints:

* The shop is already written, and is maintained internally. Ideally we
  would use a widely-tested and third-party-maintained solution, but
  that's a struggle still ahead of us. For now, we must work with our
  private code base.

* None of the developer team are have much experience with the field of
  business accounting, so if possible we need to learn from the past
  design mistakes of others without making them ourselves.

* Our application is operating in Australia, with the sales tax tracking
  requirements that come with that. Australia-specific information is
  particularly desirable.

* The business has switched to a different accounting service recently;
  it may well change again soon. We want to at least consider robustness
  of our shop's transaction tracking design in the face of a possible
  future switch to a different accounting system.

I'm happy to asnwer questions, but I'm not about to hash out the design
in this thread; that's our development team's job.

What I want is pointers to a putative “What every programmer needs to
know about storing commercial transactions for business accounting”
general guide.

Does that information already exist where I can point our team to it?

-- 
 \       “I went to a general store. They wouldn't let me buy anything |
  `\                                     specifically.” —Steven Wright |
_o__)                                                                  |
Ben Finney