Open Source Aggregator API for Accounting Software – Feedback Wanted
3 comments
Really like this direction: the pain of integrating multiple accounting systems is very real (especially when you’re building SaaS tools for global founders).
Quick question: how do you plan to deal with country-specific tax logic or weird edge cases (like German invoice sequencing or Singapore GST)?
Also, curious about auth: do you see most founders struggling with OAuth for all these platforms, or do you have plans for unified auth/session handling?
For us, data mapping and keeping invoice/customer objects in sync across platforms is always messy. Would love to hear how you’re thinking about this, especially re: long-term maintenance.
Quick question: how do you plan to deal with country-specific tax logic or weird edge cases (like German invoice sequencing or Singapore GST)?
Also, curious about auth: do you see most founders struggling with OAuth for all these platforms, or do you have plans for unified auth/session handling?
For us, data mapping and keeping invoice/customer objects in sync across platforms is always messy. Would love to hear how you’re thinking about this, especially re: long-term maintenance.
Thanks for the thoughtful questions and for sharing your experience!
On country-specific tax logic and edge cases: I’m planning to design the core with extensibility in mind—so things like tax rules, invoice sequencing, and regional compliance can be handled via plugins or configuration modules. For example, German invoice sequencing or Singapore GST could be implemented as optional adapters, and I’d love help identifying the most common patterns and pain points.
Authentication: Unified auth/session handling is a big goal, but I recognize each platform’s OAuth flow is a bit different. My idea is to abstract the common flows and provide helper functions, but also allow for custom overrides where platforms deviate too much. I’d be interested in hearing more about where OAuth gets especially tricky for your use cases.
Data mapping/sync: This is definitely the hardest part. My current thinking is to define a canonical data model (for invoices, customers, etc.), then provide mapping layers for each platform. There will be tools to help with syncing and conflict resolution, but I expect this will need ongoing refinement as APIs evolve and edge cases pop up.
Would love to keep this conversation going—if you have specific war stories or must-have features, please let me know! And if anyone’s interested in collaborating, I’d be happy to open up the repo early for feedback and contributions.
On country-specific tax logic and edge cases: I’m planning to design the core with extensibility in mind—so things like tax rules, invoice sequencing, and regional compliance can be handled via plugins or configuration modules. For example, German invoice sequencing or Singapore GST could be implemented as optional adapters, and I’d love help identifying the most common patterns and pain points.
Authentication: Unified auth/session handling is a big goal, but I recognize each platform’s OAuth flow is a bit different. My idea is to abstract the common flows and provide helper functions, but also allow for custom overrides where platforms deviate too much. I’d be interested in hearing more about where OAuth gets especially tricky for your use cases.
Data mapping/sync: This is definitely the hardest part. My current thinking is to define a canonical data model (for invoices, customers, etc.), then provide mapping layers for each platform. There will be tools to help with syncing and conflict resolution, but I expect this will need ongoing refinement as APIs evolve and edge cases pop up.
Would love to keep this conversation going—if you have specific war stories or must-have features, please let me know! And if anyone’s interested in collaborating, I’d be happy to open up the repo early for feedback and contributions.
The idea is to simplify integrations for developers who need to work with multiple accounting systems, handling authentication, data mapping, and API differences under the hood.
Would this be helpful to you? Any suggestions, feature requests, or reasons why this might not be useful? Should I go ahead and build it, or is there something similar out there already?
All feedback appreciated!