Here are some of the key integration issues I have identified working on this stuff:
(1) The actual CRM data (donor, participant, beneficiary) system of record is CiviCRM.
(2) The atomic donation system of record is CiviCRM. This is a key point... if I am asking how much money Person A gave, I look in CiviCRM. I don't look in the accounting system.
(3) The aggregate donation system of record is the accounting system. If I want to know how much money was donated last month to the organization, I ask the accounting system.
(4) They key entities in accounting systems that need to be sync'd are the invoices & the payments. As soon as you sync invoices (i.e. promises to pay that are booked to the general ledger as accounts payable) you are in for a world of complicated hurt (i.e. some folks book some types of pledges as accounts payable, others don't touch the GL until a real payment comes in).

Simplifying assumptions:
(0) CRM data in the accounting system is minimal- names and unique ID to connect back to the CRM - and it can be inaccurate (last year's donation from Jim Smith remains a donation from Jim Smith even after he changes his name to Jim Jones)
(1) Atomic donation data and aggregate donation data do not have to match exactly across systems. If CiviCRM tells me I got $15K last month and my accounting system tells me I got $14K last month (because a check bounced) that should be OK.
(2) Invoices (promises to pay) stay in the fundraising system. They only hit the accounting system when there is a GL impact (i.e. a pledge recorded as a receivable or a payment is received).

Therefore:
(1) Integration is one way: CiviCRM --> Accounting. Any Accounting --> CiviCRM integration (bounced checks) is done by hand or future integration.
(2) You generate a list of payments from CiviCRM and send them to accounting. Detailed financial reporting in the accounting system can become problematic since the financial system lacks some details.

Wrinkles: Paypal.
(1) You'll probably have to first take the payments from CiviCRM and verify they match paypal before integrating the paypal payments into accounting

What CiviCRM can do to smooth integration:
(1) Create a very clear payment entity that maps to accounting system for every monetary transaction. A contribution is a payment. A pledge fulfillment is a payment. A completed membership / event registration is a payment. (enforce the assumption that receivables generated in CiviCRM - pledge, membership w/o a check, event w/o a check never hit the GL -- somebody else can do that integration)
(2) Make sure payments can easily be reconciled with PayPal. If you can verify that all paypal payments recorded in CiviCRM actually happened, you can go straight from CiviCRM to accounting without worrying about the paypal data (The PayPal GL transaction is therefore just an account to account transfer -- no transaction data).