Skip to main content
A workspace whose books of record live in an external accounting system has to bridge two ledgers: the finance ledger GarmentFlow keeps for receivables, payables, and realized foreign-exchange gain or loss, and the general ledger of the accounting system the accountant closes the period on. For workspaces that book to 正航 / ChengHang’s T357 accounting system, GarmentFlow produces the bridge in the form 正航 reads — a 傳票 (voucher) feed that the accounting system imports into its own ledger. This page describes that feed in business terms — what it covers, how it is produced, and who consumes it. It is not a column-level specification; the shape of the voucher is fixed by 正航’s T357 template, and the workspace’s accountant works from that template directly.

​
What this feed is

A voucher (傳票) is the unit a Taiwanese accounting system books a journal entry in. Each voucher carries one or more lines, and each line attributes an amount to an accounting code — the 科目編號 the accounting system uses to organise its general ledger. The T357 voucher feed is GarmentFlow’s translation of its own ledger into that shape. Each entry on the workspace’s finance ledger — a customer-invoice charge, a customer receipt, a vendor-invoice charge, a vendor payment, a deposit applied against an invoice — becomes one voucher line in the feed. The line carries the document’s date, the counterparty (the customer for the receivables side, the vendor for the payables side), the document’s reference, the document’s own currency and rate, and the amount in the direction the accounting system expects. Realized foreign-exchange entries (the workspace’s gain or loss recognised at payment) are not included in the T357 feed — they are recognised in GarmentFlow’s own ledger in the workspace’s reporting currency, and the accounting system has its own treatment for them at month-end.

​
What it covers

The feed covers the workspace’s receivables and payables movements over a date range:
  • Customer invoices — the charges raised against customers.
  • Customer receipts — the money received against customer invoices.
  • Vendor invoices — the charges recorded against vendors.
  • Vendor payments — the money paid against vendor invoices.
  • Deposits applied against invoices — when an advance receipt is offset against an invoice raised later, the application is one entry on the feed.
Every movement in the date range is included; there is no filtering of “unposted” or “draft” movements because the feed reads from the append-only finance ledger — every entry on the ledger is permanent the moment it is recorded, and the feed reads exactly what the ledger holds. When a movement is later corrected by a reversing entry — a receipt unapplied, a vendor payment voided — both entries appear on the feed: the original entry on the date it was first recorded, and the reversal on the date the correction was made. The accounting system books both, the same way GarmentFlow’s ledger reads both. See How corrections are made.

​
How it is produced

The feed is produced as a downloadable file — Excel by default, CSV as an alternative — for a date range the workspace asks for. There is no fixed period cadence: the workspace can produce the feed for a single month, for a calendar quarter, or for any other range its accountant works in. GarmentFlow ships the voucher feed for workspaces that have been provisioned for it: the accounting-code mapping that the feed uses to translate each GarmentFlow movement category into a 正航 科目編號 is set up against the workspace’s own chart of accounts when the export is enabled. A workspace that has not been provisioned for the T357 feed does not see this export; arrange it with the GarmentFlow team if it is needed. A movement whose category has no accounting code seeded for the workspace stops the feed — the export refuses to write a voucher line it cannot attribute to a real accounting code, on the principle that an invented code would mis-book the accountant’s ledger. The workspace’s accountant supplies the missing mapping, and the feed is produced again.

​
Who consumes it

The audience for the feed is the workspace’s accountant, who imports it into 正航 to book the journal entries on the general-ledger side of the business. The accountant is not a GarmentFlow user role per se — the role inside GarmentFlow that produces the feed is Finance or Administrator. The feed is a back-office handoff, not an everyday Finance surface:
  • It does not surface as a Finance-module tab. The team does not produce a voucher feed as part of recording a receipt or approving a vendor payment — both of those record their entries on the GarmentFlow ledger, and the feed is the periodic translation of the ledger into 正航’s shape.
  • It does not change anything inside GarmentFlow. The feed is read-only on the GarmentFlow side — producing it does not post a ledger entry, does not mark a movement as “exported,” and does not gate further movements. The same date range can be produced more than once with the same result.
  • It is the only export the platform produces in 正航’s T357 voucher shape. The Finance module’s Reports tab produces generic Excel and CSV exports for the workspace’s own reading; the T357 feed is the separate handoff for the accounting system.

​
What is not in the feed

The feed is the receivables / payables bridge. It deliberately leaves to the accounting system the parts the accounting system books on its own side:
  • The bank or revenue side of each journal entry. The feed writes the receivables or payables side — the side GarmentFlow knows about; 正航 books the bank, sales, or expense side from its own contra rules.
  • Realized foreign-exchange gain or loss. Recognised on GarmentFlow’s foreign-exchange ledger side in the workspace’s reporting currency; the accounting system has its own treatment.
  • Workspace cost reporting. The cost allocation overlay and the Order Profit / Customer Profit rollups are read-time reporting views on GarmentFlow’s own side. They are not booked anywhere, in either ledger.
The feed’s job is to keep the two ledgers reconciled at the receivables-and-payables boundary; everything that lives on only one side stays on that side.