What should I understand about FieldEdge and its accounting sync before committing?

Two-way sync is a coupling decision

A one-way push is simple: the field service system produces invoices, accounting receives them, and if the connection breaks you have a backlog to replay. A two-way sync is different in kind. Customers, items and payments can originate in either system, which means both are authoritative for something and neither is authoritative for everything.

That coupling is genuinely useful — it is why office staff stop re-keying invoices — but it needs an explicit ownership map, written down, before anyone turns it on.

Write the ownership map first

• Customers. Pick one origin. Customers created in both places produce duplicates that are painful to merge after history accumulates.
• Items and services. The pricebook should own these. Ad-hoc items created on invoices are the most common source of mapping errors.
• Invoices. Almost always originate in the field service system. Edits made afterward in accounting are the classic drift source.
• Payments. Decide whether the payment processor, the field service system or accounting is the truth, especially for partial payments and credits.
• Tax. Rate tables in two systems will disagree eventually. Nominate one and derive the other.

Failure modes worth monitoring

Sync errors are usually not dramatic. A record fails validation, lands in a queue, and everything else keeps flowing. Nobody notices until a month-end reconciliation is short and someone spends two days finding it.

Treat the sync error queue as an operational metric with an owner and a daily glance, the same way you would treat unassigned jobs. If the connector produces a log, get it into whatever people already look at every morning — this is a natural item for a daily operations brief rather than something buried in a settings screen.

Desktop and hosted accounting are different problems

If your accounting runs on a desktop or hosted-desktop installation, the sync depends on that machine being awake, connected and running the right version. That is a real availability dependency and it belongs in your risk list. Cloud-to-cloud connections remove that failure mode and introduce their own around authentication token expiry.

Neither is disqualifying. Both need someone responsible for noticing when they stop. If you are building reporting on top of this data, understand that revenue reporting should read from a clearly nominated source rather than whichever system happens to be handy — otherwise your dashboard becomes a third opinion in an argument that already had two.